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(57) Abstract 

An Intranet/Internet/Web-based data management tool that provides a common GUI enabling the requesting, customizing, scheduling 
and viewing of various types of priced call detail data reports pertaining to a customer's usage of telecommunications services. 
The Web-based reporting system tool comprises a novel Web-based, client-server application integrated with an operational data 
management/storage infrastructure that enables customers to access their own relevant data information timely, rapidly and accurately 
through the GUI client interface. The data management system infrastructure is designed to enable the secure initiation, acquisition, and 
presentation of telecommunications priced call detail data reports to customer workstations (51) implementing a web browser (50). 
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INTEGRATED PROXY INTERFACE FOR WEB BASED DATA 
MANAGEMENT REPORTS 

The present, invention relates generally to 
information delivery systems and, particularly, to a 
novel, World Wide Web/Internet -based , 

telecommunications network data management reporting 
and presentation service for customers of 
telecommunications service entities . 

Telecommunications service entities, e.g., 
MCI, AT&T, Sprint, and the like, presently provide for 
the presentation and dissemination of customer account 
and network data management information to their 
customers predominantly by enabling customers (clients) 
to directly dial-up, e.g., via a modem, to the entity's 
application servers to access their account 
information, or, alternately, via dedicated 
communication lines, e.g., ISDN, T-l, etc., enabling 
account information requests to be initiated through 
their computer terminal running, for example, a 
Windows®-based graphical user interface. The requests 
are processed by the entity's application servers, 
which retrieves the requested customer information, 
e.g., from one or more databases, processes and formats 
the information for downloading to the client's 
computer terminal . 

Some types of data, e.g., "priced" call 
detail data pertaining to a customer's 

telecommunications number usage, is made available for 
customers in an aggregated or processed form and 
provided to customers, e.g., on a monthly basis. This 
type of data is analyzed to determine, for example, 
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asset usage and trend information necessary, which xs 
required for network managers to make critical business 
decisions. As an example, the assignee 

telecommunications carrier MCI Corporation provides an 
MCI ServiceView ( «MSV» ) product line for its business 
customers which includes several client - server based 
data management applications. One of these 
applications, referred to as "Perspective", provides 
call usage and analysis information that focuses on the 
presentation of and priced call detail data and reports 
from an MCI Perspective Data Server ("StarPR"). 
Another client - server based data management 
application, referred to as "Traffic View", focuses on 
the presentation of real time call detail data and 
network traffic analysis/monitor information as 
provided from an MCI Traffic view server. 
Particularly, with respect to MCI's Perspective system, 
customers are provided with their monthly priced and 
discounted raw call detail data, call detail 
20 aggregates, and statistical historical summary data. 

As such, the Perspective architecture is organized 
primarily as a batch midrange-based server data 
delivery mechanism with the data being typically 
delivered on a monthly basis, allowing for "delayed" 
25 trending, call pattern analysis, repricing and invoice 

validation based on the customer's call detail data. 
• The trending, analysis, and repricing functionality is 
maintained in workstation-based software provided to 
customers for installation at customer sites on their 
30 PCS . 



15 
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Figure 1 illustrates the current architecture 
10 for Perspective and Traffic View Systems which 
presently run on separate environments and are 
maintained independently of each other. The StarPR 
server provides a batch reporting mechanism focused 
primarily on providing billing data to l-800/8xx, VNET, 
Vision, and other MCI customers and is used by MCI 
customers predominantly to do internal charge backs and 
to analyze billing usage. Alternately, or in addition, 
the customers use the data provided to them to do call 
traffic analysis, similar to TVS. 

With specific reference to Figure 1, the data 
collected is in the form of call detail records which 
are created by various MCI/Concert switches (not shown) 
whenever a telephone call is attempted in the MCI 
network and which includes information about call type, 
call origination and termination locations, date and 
time, added intelligent network services, any hop 
information, product type and other relevant 
information about the call. The Network Information 
Concentrator ("NIC") component 15 is a network element 
that collects the CDRs and sends them to appropriate 
locations via a Global Statistical Engine 17. The 
Global Statistical Engine 17 collects the CDRs and 
transforms, processes, and sends them to the TVS 20. 
The TVS provides access to this data through various 
statistical reports and real time monitoring engine 22 
( "RTM" ) . 

The CDRs from are also sent to the billing 
system which applied billing based on call detail 
values. These "priced" CDRs are known as Billing 

-3- 



SUBSTITUTE SHEET (RULE 26) 



WO 99/16207 



PCT/US98/20148 



10 



20 



25 



30 



Detail Records ( "BDRs" ) and are sent to a Perspective 
Host ("Phost") server 25. The Phost server 25 filters 
out the BDRs not pertaining to the "Perspective- 
customers, applies various transformations to the 
customer's raw call detail data to generate summary 
data, and generates and formats the data for the 
various Perspective customers. This data is then 
compressed, sent to a document service center ( "DSC" ) 
and CD-ROM dispatcher ( "CDD" ) 34 entities which 
respectively, uncompresses the data and burns CD-ROMs 
comprising the customer's raw call detail data and 
summary data, in addition to reference files and 
possibly application software (if not previously owned) 
enabling customers to perform analysis and trending of 
their Perspective data. These CD-ROMs are sent to the 
customers, usually on a billing cycle or monthly basxs, 
who view their data through a Perspective workstation - 
based software application residing on that customer's 
CPE, e.g., PC or workstation 36. 

As shown in Figure 1, the existing 
Perspective Host 25 mainframe -based data delivery 
system interfaces with all Perspective upstream feed 
systems, including billing systems and order entry, and 
processes the data, e.g., creates canned aggregates, 
for delivery to the document service center. 

The following upstream feed systems include: 
1) order entry information from a customer order entry 
system 19 ("CORE") and which information is used by the 
Perspective Host to determine what customer data to 
process and where to send it; 2) VNET and Vision 
monthly billing data feeds from a commercial billing 
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system ("NBCS") system 23; 3) a Toll-free monthly 
billing data feed from a T/F database feed 27; and, a 
Concert Virtual Network Services ("CVNS") product feed 
from a CVNS database 31. In order for all the CDR and 
data feed information to be processed by the Phost 
server 25, various reference files and processing rules 
are provided including: alphanumeric translation 
reference files from the NCBS billing system 23 and an 
NPA/NXX- state- city and country code lookup reference 
file originating from a calling area data base ( "CADB" ) 
35 . 

While effective for its purpose, the current data 
management and presentation architecture only provides 
customers with their priced call detail data on a 
monthly basis, usually in the form of a canned report. 
This is not sufficient for an increasing number of 
customers who, to remain competitive, are required to 
have updated and real-time access to their data to 
enable them to make their critical business decisions 
quicker. Moreover, there are a variety of independent 
data management tools and legacy reporting systems 
having disparate systems and infrastructures providing 
little or no cross application interoperability and 
data sharing, thus, requiring customers to use separate 
applications to gain access to their data. 

Furthermore , existing telecommunications 
service provider reporting systems are limited in that 
reports generated are of a narrow view, and are 
delivered at predetermined times with predetermined 
formats. These prior art reporting systems do not 
enable the generation of ad-hoc reports. Moreover, 
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le gacy Platform incluaing reporting aata are reaching 
h I architectural limits c £ scalability in ter.s c tbe 
total customers they can support, total online aata 
1 an oresent. total historical aata they can Keep 
r/re a -umber o £ applications they can support 

It would thus be highly aesirahle to proviae 
a aata - M « t proauct that is a Web-based .Internet 
and Untranet, client - server application P-v^n 
priced call aetail aata information to customers i . 
variety of aetailea report formats comprising specific 
r-nstomer account information. 

It wouia aaaitionally be highly aesrrable to 

for a web-basea client - server applicatro ^ 
provides expeaient ana -cure aata access ^ 
services to customers at any time, from ay 
on any computer terminal anywhere 

The present invention is directea to a 
novel imtranet/mternet/web-basea aata management 
tool that proviaes a common GUI enabling the 
revesting, customizing, scaling ana viewing of 
various types of pricea call aetail aata reports 
pertaining to a customer's usage of 
telecommunications services. The 
Ltranet/mternet/web-basea reporting system tool 
comprises a novel web-basea. client-server 
application integrated with an operational aata 
Inagement/storage infrastructure tbat enables 
easterners to access their own relevant tota 
information timely, rapiaiy ana accurately through 
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the GUI client interface. The operational database 
system infrastructure particularly is configured tc 
meet a customer's real-time data processing and 
storage requirements and is easy to deploy and 
manage, and further, ensures upward and downward 
scalability. It enables effective storage of data 
from a variety of independently developed legacy 
systems and, is readily integrated into a novel 
Web-based (Internet and Intranet) reporting system 
tool that enables customers to customize and 
directly access their own relevant data report 
information. The world wide web/Internet -based 
client - server data management and reporting tool 
employs a platform- independent , i.e., JAVA-based, 
network centric GUI client presentation layer and 
an objects/dispatcher/proxy layer access 
archi tecture . 

Particularly, the telecommunications data 
management/system architecture is integrated with a 
novel Web/Internet based reporting system, referred 
to as networkMCI Interact ("nMCI"). The back-end 
data management/system architecture, referred to 
herein as "StarODS" , implements a Data Warehouse 
approach to maintaining data obtained from upstream 
billing systems, i.e., priced call detail data, and 
which data may be made readily available for 
reporting on a daily basis. In this approach, 
priced call detail data is maintained in datamarts 
and operational data stores capable of meeting 
real-time processing and storage requirements. 
Particularly, these datamarts may be partitioned 
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based on various criteria, e.g., customer id, to 
enable easier management of data by providing 
scalability, and enabling more control of over 
hardware and software resources, in a cost- 
5 effective way. Included in this datamart approach 

is a back-end server component provided to receive 
data access requests from various users in the form 
of a report request, interactive data analysis 
request or data mining request. This server routes 
,0 the query to the appropriate data marts, data 

warehouse or operational data store and responds to 
the requestor with the result set. 

The nMCI Interact system is a layer 
functioning to enable customers to request 
, 5 reporting functionality across the Internet. This 

report request functionality includes routing 
requests to appropriate datamarts , e.g., real-time 
reporting requests will be satisfied by real-time 
database. Additionally, the interface provides 
customers with the ability to schedule and 
prioritize reports, format report request result 
sets, and provides for load balancing, report 
request validation, query generation and execution. 
Through a common GUI, customers are enabled to 
access their own metered data, i.e., Perspective or 

usage analysis data. 

in accordance with the principles of the 

present invention, there is provided a 
Web/Internet based reporting system for 
30 communicating data information from an enterprise 
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25 
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intranet database to a client terminal via an 
integrated interface comprising: 

a client browser application located at the client 
terminal for enabling interactive Web based 
5 communications with the reporting system, the 

client terminal identified with a customer and 
providing the integrated interface; at least one 
secure server for managing client sessions over the 
Internet, the secure server supporting a first 
10 secure socket connection enabling encrypted 

communication between the browser application 
client and the secure server; a dispatch server for 
communicating with the secure server through a 
firewall over a second socket connection, the first 
15 secure and second sockets forming a secure 

communications link, the dispatch server enabling 
forwarding of a report request message and an 
associated report response message back to the 
client browser over the secure communications link; 
20 a report manager server for maintaining an 

inventory of reporting items associated with a 
customer and managing the reporting of customer - 
specific data information in accordance with a 
customer request message, the report manager 
25 -accessing reporting items based on a customer 

identity and report name from a first database, and 
generating a response message including a metadata 
description of the reporting items; and, decision 
support server interfacing with the report manager 
30 for accessing the customer- specif ic data from the 

enterprise intranet database in accordance with the 
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customer identity and report name, wherein the 
retrieved data and the metadata description of the 
reporting item are utilized to generate a completed 
report for presentation to the customer via the 
interface. 

Advantageously, the novel Web/Internet 
based reporting system integrated with the data 
management system permits use of existing hardware 
while allowing future growth to utilize new 
equipment at less cost and further, allows for 
incremental expansion as applications and database 

capacities grow. 

Further features and advantages of the 
invention will become more readily apparent from a 
consideration of the following detailed description 
set forth with reference to the accompanying 
drawings, which specify and show preferred 
embodiments of the invention, wherein like elements 
are designated by identical references throughout 
the drawings; and in which: 

Figure 1 illustrates conceptually an 

existing mainframe -based data delivery system 10 

providing customer's call detail data; 

Figure 2 illustrates the software 

architecture component comprising a three- tiered 

structure; 

Figure 3 is a diagrammatic overview of 

the software architecture of the networkMCI 

Interact system; 

Figure 4 is an illustrative example of a 

backplane architecture schematic; 
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Figure 5 illustrates an example client 
GUI presented to the client/customer as a browser 
web page; 

Figure 6 is a diagram depicting the 
5 physical networkMCI Interact system architecture ; 

Figure 7 is a block diagram depicting the 
physical architecture of the StarWRS component of 
networkMCI Interact Reporting system; 

Figure 8 illustrates the primary 
10 components implemented in the StarODS priced 

reporting component 4 00; 

Figure 9 illustrates the data model 
implemented for accessing information used in 
priced reporting system of nMCI Interact; 
15 Figure 10(a) illustrates the logical 

Report Manager/DSS application programming 
interface ; 

Figure 10(b) illustrates the logical 
DSS/Report Manager application programming 
20 interface; 

Figures 11(a) -1Kb) illustrate an 
overview of the process performed by the DSS in 
routing a request; 

Figure 12(a) illustrates an overview of 
25 the DSS connections enabling guaranteed message 

delivery in the nMCI Interact System; 

Figure 12 (b) illustrates the formatter 
process implemented in the DSS server; 

Figures 13 (a) -13(c) illustrate the end- 
30 to-end process 600 for fulfilling priced report 

request ; 
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Figure 14 illustrates a logical message 
format sent from the client browser to the desired 
middle tier server for a particular application; 
and 

Figures 15(a) and 15(b) are schematic 
illustrations showing the message format passed 
between the Dispatcher server and the applicatxon 
specific proxy (Figure 15(a)) and the message 
format passed between the application specific 
proxy back to the Dispatcher server (Figure 15(b)). 

The present invention is one component of 
an integrated suite of customer network management 
and report applications using a Web browser 
paradigm. Known as the networkMCI Interact system 
rnMCI interact") such an integrated suite of Web- 
based applications provides an invaluable tool for 
enabling customers to manage their 

•^♦.-irvr. S Qqpts auickly and securely, 
telecommunication assets, ^ U - L ^ rv y 

from anywhere in the world. 

The nMCI Interact system architecture is 
basically organized as a set of common components 
comprising the following: 

1) an object-oriented software 
architecture detailing the client and server based 
aspect of nMCI Interact; 

2) a network architecture defining the 
physical network needed to satisfy the security and 
data volume requirements of the networkMCI System; 

3) a data architecture detailing the 
application, back-end or legacy data sources 
available for networkMCI Interact; and 
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4) an infrastructure covering security, 
order entry, fulfillment, billing, self -monitoring , 
metrics and support. 

Each of these common component areas will 
be generally discussed hereinbelow. 

Figure 2 is a diagrammatic illustration 
of the software architecture component in which the 
present invention functions. A first or client 
tier 40 of software services are resident on a 
customer work station and provides customer access 
to the enterprise system, having one or more 
downloadable application objects directed to front 
end business logic, one or more backplane service 
objects for managing sessions, one or more 
presentation services objects for the presentation 
of customer options and customer requested data in 
a browser recognizable format and a customer 
supplied browser for presentation of customer 
options and data to the customer and for internet 
communications over the public Internet. 
Additionally applications are directed to front end 
services such as the presentation of data in the 
form of tables and charts, and data processing 
functions such as sorting and summarizing in a 
manner such that multiple programs are combined in 
a unified application suite. A second or middle 
tier 42, is provided having secure web servers and 
back end services to provide applications that 
establish user sessions, govern user authentication 
and their entitlements, and communicate with 
adaptor programs to simplify the interchange of 
data across the network. 

A third or back end tier 4 5 having 
applications directed to legacy back end services 
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including database storage and retrieval systems 
and one or more database servers for accessing 
system resources from one or more legacy hosts. 

Generally, the customer workstation 
includes client software capable of providing a 
platform- independent, browser -based, consistent 
user interface implementing objects programmed to 
provide a reusable and common GUI abstraction and 
problem- domain abstractions. More specifically, 
the client-tier software is created and distributed 
as a set of Java classes including the applet 
classes to provide an industrial strength, object- 
oriented environment over the Internet. 
Application- specific classes are designed to 
support the functionality and server interfaces for 
each application with the functionality delivered 
through the system being of two -types: 1) cross- 
product, for example, inbox and reporting 
functions, and 2) product specific for example, 
toll free network management or Call Manager 
functions. The system is capable of delivering to 
customers the functionality appropriate to their 

product mix. 

Figure 3 is a diagrammatic overview of 

the software architecture of the networkMCI 
interact system including: the Customer Browser 
(a.k.a. the Client) 50; the Demilitarized Zone 
(DMZ) 47 comprising a Web Servers cluster 44; the 
■ MCI intranet Dispatcher Server 46; and the MCI 
intranet Application servers 60, and the data 
warehouses, legacy systems, etc. 80. 

A customer workstation 51 employs a Web 
Browser 50 implementing client applications 
responsible for presentation and front-end 
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services. Its functions include providing a user 
interface to various MCI services and supporting 
communications with MCI's Intranet web server 
cluster 44. As illustrated in Figure 3, the client 
tier software is responsible for presentation 
services to the customer and generally includes a 
web browser 50 and additional object-oriented 
programs residing in the client workstation 
platform 51. The client software is generally 
organized into a component architecture with each 
component generally comprising a specific 
application, providing an area of functionality. 
The applications generally are integrated using a 
"backplane" services layer 52 which provides a set 
of services to the application objects which 
provide the front end business logic and manages 
their launch. The networkMCI Interact common set 
of objects provide a set of services to each of the 
applications such as: 1) session management; 2) 
application launch; 3) inter-application 
communications; 4) window navigation among 
applications; .5) log management; and 6) version 

management . 

The primary common object services 

25 include: graphical user interface (GUI) ; 

communications; printing; user identity, 
authentication, and entitlements; data import and 
export; logging and statistics; error handling; and 

messaging services. 

Figure 4 is a diagrammatic example of a 
backplane architecture scheme illustrating the 
relationship among the common objects. In this 
example, the backplane services layer 52 is 
programmed as a Java applet which can be loaded and 
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launched by the web browser 50. With reference to 
Figure 4, a typical user session starts with a web 
browser 50 creating a backplane 52, after a 
successful logon. The backplane 52, inter alia, 
presents a user with an interface for networkMCI 
interact application management. A typical user 
display provided by the backplane 52 may show a 
number of applications the user is entitled to run, 
each application represented by buttons depicted in 
Figure 4 as buttons 58a, b,c selectable by the user. 
As illustrated in Figure 4, upon selection of an 
application, the backplane 52 launches that 
specific application, for example, Service Inquxry 
54a or Alarm Monitor 54b, by creating the 
application object. In processing its functions, 
each application in turn, may utilize common object 
services provided by the backplane 52 . Figure 4 
shows graphical user interface objects 56a, b 
created and used by a respective application 54a, b 
for its own presentation purposes. 

Figure 5 illustrates an example client 
GUI presented to the client/customer as a browser 
web page 71 providing, for example, a suite 70 of 
network management reporting applications 
including: MCI Traffic Monitor 72; an alarm monrtor 
73; a Network Manager 74 and Intelligent Routing 
75. Access to network functionality is also 
provided through Report Requester 76, which 
provides a variety of detailed reports for the 
client/customer and a Message Center 77 for 
providing enhancements and functionality to 
traditional e-mail communications. 

As shown in Figures 3 and 4 , the browser 
resident GUI of the present invention implements a 
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single object, COBackPlane which keeps track of all 
the client applications, and which has capabilities 
to start, stop, and provide references to any one 
of the client applications. 
5 The backplane 52 and the client 

applications use a browser 50 such as the Microsoft 
Explorer versions 4.0.1 or higher for an access and 
distribution mechanism. Although the backplane is 
initiated with a browser 14, the client 
10 applications are generally isolated from the 

browser in that they typically present their user 
interfaces in a separate frame, rather than sitting 
inside a Web page. 

The backplane architecture is implemented 
15 with several primary classes. These classes 

include COBackPlane, COApp, COAppImpl, COParm. and 
COAppFrame classes. COBackPlane 52 is an 
application backplane which launches the 
applications 54a, 54b, typically implemented as 
20 COApp. COBackPlane 52 is generally implemented as 

a Java applet and is launched by the Web browser 
50. This backplane applet is responsible for 
launching and closing the COApp s . 

When the backplane is implemented as an 
25 applet, it overrides standard Applet methods 

initO, start (), stopO and run ( ) . In the initO 
method, the backplane applet obtains a COUser user 
context object. The COUser object holds 
information such as user profile, applications and 
30 their entitlements. The user's configuration and 

application entitlements provided in the COUser 
context are used to construct the application 
toolbar and Inbox applications. When an 
application toolbar icon is clicked, ,a particular 
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COApp is launched by launchAppO method. The 
launched application then may use the backplane for 
inter -application communications, including 

retrieving Inbox data. 

The COBackPlane 52 includes methods for 
providing a reference to a particular COApp, for 
interoperation. For example, the COBackPlane class 
provides a getAppO method which returns references 
to application objects by name. Once retrieved xn 
this manner, the application object's public 
interface may be used directly. 

As shown in Figure 3, the aforesaid 
objects will communicate the data by establishing a 
secure TCP messaging session with one of the DMZ 
networkMCI Interact Web servers 44 via an Internet 
secure communications path 32 established, 
preferably, with a secure sockets SSL version of 
HTTPS. The DMZ networkMCI Interact Web servers 44 
function to decrypt the client message, preferably 
via the SSL implementation, and unwrap the session 
key and verify the users session. After 
establishing that the request has come from a valid 
user and mapping the request to its associated 
session, the DMZ Web servers 44 will re-encrypt the 
25 request using symmetric encryption and forward it 

over a second socket connection 33 to the dispatch 
server 46 inside the enterprise Intranet. 

A networkMCI Interact session is 
designated by a logon, successful authentication, 
followed by use of server resources, and logoff. 
However, the world-wide web communications protocol 
uses HTTP, a stateless protocol, each HTTP request 
and reply is a separate TCP/IP connection, 
completely independent of all previous or future 
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connections between the same server and client. 
The nMCI Interact system is implemented with a 
secure version of HTTP such as S-HTTP or HTTPS , and 
preferably utilizes the SSL implementation of 
HTTPS. The preferred embodiment uses SSL which 
provides a cipher spec message which provides 
server authentication during a session. The 
preferred embodiment further associates a given 
HTTPS request with a logical session which is 
initiated and tracked by a "cookie jar server" 48 
to generate a "cookie" which is a unique server- 
generated key that is sent to the client along with 
each reply to a HTTPS request. The client holds 
the cookie and returns it to the server as part of 
each subsequent HTTPS request. As desired, either 
the Web servers 44, the cookie jar server 48 or the 
Dispatch Server 46, may maintain the "cookie jar" 
to map these keys to the associated session. A 
separate cookie jar server 48, as illustrated in 
Figure 3 has been found desirable to minimize the 
load on the dispatch server 46. This form of 
session management also functions as an 
authentication of each HTTPS request, adding an 
additional level of security to the overall 
process . 

As illustrated in Figure 3, after one of 
the DMZ Web servers 44 decrypts and verifies the 
user session,. it forwards the message through a 
firewall 55b over a TCP/IP connection 33 to the 
dispatch server 46 on a new TCP socket while the 
original socket. 32 from the browser is blocking, 
waiting for a response. The dispatch server 46 
will unwrap an outer protocol layer of the message 
from the DMZ services cluster 44, and will 
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reencrypt the message with symmetric encryption and 
forward the message to an appropriate application 
proxy via a third TCP/IP socket 37. While waiting 
for the proxy response, all three of the sockets 
32, 33, 37 will be blocking on a receive. 
Specifically, once the message is decrypted, the 
wrappers are examined to reveal the user and the 
target middle- tier (Intranet application) servo.ce 
for the request. A first-level validation is 
performed, making sure that the user is entitled to 
communicate with the desired service. The user's 
entitlements in this regard are fetched by the 
dispatch server 46 from StarOE server 69 at logon 

time and cached. 

If the requestor is authorized to 
communicate with the target service, the message is 
forwarded to the desired service's proxy. Each 
application proxy is an application specific daemon 
which resides on a specific Intranet server, shown 
in Figure 3 as a suite of mid- range servers 60. 
Each intranet application server of suite 60 is 
generally responsible for providing a specific 
back-end service requested by the client, and, is 
additionally capable of requesting services from 
other intranet application servers by communicating 
to the specific proxy associated with that other 
application server. Thus, an application server not 
only can offer its browser a client to server 
interface through the proxy, but also may offer all 
30 its services from its proxy to other application 

servers. in effect, the application servers 
requesting service are acting as clients to the 
application servers providing the service. Such 
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mechanism increases the security of the overall 
system as well as reducing the number of 
interfaces . 

The network architecture of Figure 3 may 
also include a variety of application specific 
proxies having associated Intranet application 
servers including: a StarOE proxy for the StarOE 
application server 69 for handling authentication 
order entry/billing; an Inbox proxy for the Inbox 
application server 61, which functions as a 
container for completed reports, call detail data 
and marketing news messages, a Report Manager Proxy 
capable of communicating with a system- specif ic 
Report Manager server 62 for generating, managing 
and scheduling the transmission of customized 
reports including, for example: call usage analysis 
information provided from the StarODS server 63; 
network traffic analysis/monitor information 
provided from the Traffic view server 64; virtual 
data network alarms and performance reports 
provided by Broadband server 65; trouble tickets 
for switching, transmission and traffic faults 
provided by Service Inquiry server 66; and toll 
free routing information provided by Toll Free 
Network Manager server 67. 

As partially shown in Figure 3, it is 
understood that each Intranet server of suite 60 
communicates with one or several consolidated 
network databases which include each customer's 
network management information and data. In the 
present invention the Services Inquiry server 36 
includes communication with MCI ' s Customer Service 
Management legacy platform 80(a). Such network 
management and customer network data is 
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additionally accessible by authorized MCI 
management personnel. As shown in Figure 3, other 
legacy platforms 80(b), 80(c) and 80(d) may also 
communicate individually with the Intranet servers 
for servicing specific transactions initiated at 
the client browser. The illustrated legacy 
platforms 80 (a) - (d) are illustrative only and it is 
understood other legacy platforms may be 
interpreted into the network architecture 
illustrated in Figure 3 through an intermediate 

midrange server 60. 

Each of the individual proxies may be 
maintained on the dispatch server 46, the related 
application server, or a separate proxy server 
situated between the dispatch server 46 and the 
midrange server 30. The relevant proxy waits for 
requests from an application client running on the 
customer's workstation 50 and- then services the 
request, either by handling them internally or 
forwarding them to its associated Intranet 
application server 60. The proxies additionally 
receive appropriate responses back from an Intranet 
application server 60. Any data returned from the 
Intranet application server 60 is translated back 
to client format, and returned over the internet to 
the client workstation 50 via the Dispatch Server 
46 and at one of the web servers in the DMZ 
Services cluster 44 and a secure sockets 
connection. When the resultant response header and 
trailing application specific data are sent back to 
the client browser from the proxy, the messages 
will cascade all the way back to the browser 14 in 
real time, limited only by the transmission latency 
speed of the network. 
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The networkMCI Interact middle tier 
software includes a communications component 
offering three (3) types of data transport 
mechanisms: 1) Synchronous; 2) Asynchronous; and 3) 
Bulk transfer. Synchronous transaction is used for 
situations in which data will be returned by the 
application server 60 quickly. Thus, a single TCP 
connection will be made and kept open until the 
full response has been retrieved. 

Asynchronous transaction is supported 
generally for situations in which there may be a 
long delay in application server 60 response. 
Specifically, a proxy will accept a request from a 
customer or client 50 via an SSL connection and 
then respond to the client 50 with a unique 
identifier and close the socket connection. The 
client 50 may then poll repeatedly on a periodic 
basis until the response is ready. Each poll will 
occur on a new socket connection to the proxy, and 
the proxy will either respond with the resultant 
data or, respond that the request is still in 
progress. This will reduce the number of resource 
consuming TCP connections open at any time and 
permit a user to close their browser or disconnect 
a modem and return later to check for results. 

Bulk transfer is generally intended for 
large data transfers and are unlimited in size. 
Bulk transfer permits cancellation during a 
transfer and allows the programmer to code 
resumption of a transfer at a later point in time. 

Figure 6 is a diagram depicting the 
physical networkMCI Interact system architecture 
100. As shown in Figure 6, the system is divided 
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into three major architectural divisions including: 
1) the customer workstation 50 which include those 
mechanisms enabling customer connection to the 
Secure web servers 44; 2) a secure network area 47, 
known as the DeMilitarized Zone "DMZ" set aside on 
MCI premises double firewalled between the both the 
public internet 85 and the MCI Intranet to prevent 
potentially hostile customer attacks; and, 3) the 
MCI intranet Midrange Servers 60 and Legacy 
Mainframe Systems 80 which comprise the back end 
business logic applications. 

As illustrated in Figure 6, the present 
invention includes a double or complex firewall 
system that creates a "demilitarized zone" (DMZ) 
between two firewalls 55a. 55b. In the preferred 
embodiment, one of the firewalls 55b includes port 
specific filtering routers, which may only connect 
with a designated port address. For example, 
router 84 (firewall 55(a)) may connect only to the 
addresses set for the HydraWeb* (or web servers 44) 
within the DMZ, and router 86 (firewall 55(b)) may 
only connect to the port addresses set for the 
dispatch server 46 within the network. In 
addition, the dispatch server 46 connects with an 
authentication server, and through a proxy firewall 
to the application servers. This ensures that even 
if a remote user ID and password are hijacked, the 
only access granted is to one of the web servers 44 
or to intermediate data and privileges authorized 
for that user. Further, the hijacker may not 
directly connect to any enterprise server in the 
enterprise intranet beyond the DMZ, thus ensuring 
internal company system security and integrity. 
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Even with a stolen password, the hijacker may not 
connect to other ports, root directories or 
application servers within the enterprise system, 
and the only servers that may be sabotaged or 
controlled by a hacker are the web servers 44. 

The DMZ 47 acts as a double firewall for 
the enterprise intranet because of the double layer 
of port specific filtering rules. Further, the web 
servers 44 located in the DMZ never store or 
compute actual customer sensitive data. The web 
servers only transmit the data in a form suitable 
for display by the customer's web browser. Since 
the DMZ web servers do not store customer data, 
there is a much smaller chance of any customer 
information being jeopardized in case of a security 
breach. In the preferred embodiment, firewalls or 
routers 84,86 are a combination of circuit gateways 
and filtering gateways or routers using packet 
filtering rules to grant or deny access from a 
source address to a destination address. All 
connections from the internal application servers 
are proxied and filtered through the dispatcher 
before reaching the web servers 44. Thus it 
appears to any remote site, that the connection is 
really with the DMZ site, and identity of the 
internal server is doubly obscured. This also 
prevents and direct connection between any external 
and any internal network or intranet computer. 

The filtering firewalls 55 (a) , (b) may 
also pass or block specific types of Internet 
protocols. For example, FTP can be enabled only 
for connections to the In -Box server 61, and denied 
for all other destinations. SMTP can also be 
enabled to the In -Box server, but Telnet denied. 
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The in-box server 61 is a store and forward server 
for client designated reports, but even in this 
server, the data and meta-data are separated to 

s<? will be described, 
further secure the data, as wuj. 

As previously described, the customer 
access mechanism is a client workstation 51 
employing a Web browser 50 for providing the access 
to the networkMCI Interact system via the public 
internet 85. When a subscriber connects to the 
networkMCI Interact Web site by entering the 
appropriate URL, a secure TCP/IP communications 
link 32a is established to one of several Web 
servers 44 located inside a first firewall 55a in 
the DMZ 47. Preferably at least two web servers 
are provided for redundancy and failover 
capability. In the preferred embodiment of the 
invention, the system employs SSL encryption so 
that communications in both directions between the 
subscriber and the networkMCI Interact system are 
secure . 

in the preferred embodiment, all DMZ 
Secure Web servers 44 are preferably DEC 4100 
systems having Unix or NT-based operating systems 
for running services such as HTTPS , FTP, and Telnet 
over TCP/IP • The web servers may be interconnected 
by a fast Ethernet LAN running at 100 Mbit/sec or 
greater, preferably with the deployment of switches 
within the Ethernet LANs for improved bandwidth 
utilization. One such switching unit included as 
part of the network architecture is a HydraWEB® unit 
82 manufactured by HydraWEB Technologies, Inc.. 
which provides the DMZ with a virtual IP address so 
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that subscriber HTTPS requests received over the 
Internet will always be received. The Hydraweb® 
unit 82 implements a load balancing algorithm 
enabling intelligent packet routing and providing 
5 optimal reliability and performance by guaranteeing 

accessibility to the "most available" server. It 
particularly monitors all aspects of web server 
health from CPU usage, to memory utilization, to 
available swap space so that Internet /Intranet 

10 networks can increase their hit rate and reduce Web 

server management costs. In this manner, resource 
utilization is maximized and bandwidth (throughput) 
is improved. It should be understood that a 
redundant Hydraweb® unit may be implemented in a 

15 Hot/Standby configuration with heartbeat messaging 

between the two units (not shown) . Moreover, the 
networkMCI Interact system architecture affords web 
server scaling, both in vertical and horizontal 
directions. Additionally, the architecture is such 

20 that new secure web servers 44 may be easily added 

as customer requirements and usage increases. 

As shown in Figure 6, the most available 
Web server 44 receives subscriber HTTPS requests, 
for example, from the HydraWEB® 82 over a connection 

25 44b and generates the appropriate encrypted 

messages for routing the request to the appropriate 
MCI Intranet midrange web server over connection 
44a, router 86 and connection 44b. Via the 
Hydraweb® unit 82, a TCP/IP connection 38 links the 

30 Secure Web server 44 with the MCI Intranet 

Dispatcher server 46. 
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Further as shown in the DMZ 47 is a 
second RTM server 92 having its own connection to 
the public internet via a TCP/IP connection 88. 
This RTM server provides real-time session 
5 management for subscribers of the networkMCI 

Interact Real Time Monitoring system. An additional 
TCP/IP connection 88a links the RTM Web server 92 
with the MCI intranet Dispatcher server 46. As 
further shown in Figure 6, a third router 87 is 
10 provided for routing encrypted subscriber messages 

from the RTM Web server 92 to the Dispatcher server 
46 inside the second firewall. Although not shown, 
each of the routers 86, 87 may additionally route 
signals through a series of other routers before 
15 eventually being routed to the nMCl Interact 

Dispatcher server 46. In operation, each of the 
Secure servers 44 function to decrypt the client 
message, preferably via the SSL implementation, and 
unwrap the session key and verify the users session 
20 from the COUser object authenticated at Logon. 

After establishing that the request has 
come from a valid user and mapping the request to 
its associated session, the Secure Web servers 44 
will re -encrypt the request using symmetric RSA 
25 encryption and forward it over a second socket 

connection 3 8 to the dispatch server 46 inside the 
enterprise Intranet. 

As described herein, the data 
architecture component of networkMCI Interact 
30 reporting system is focused on the presentation of 

real time (un- priced) call detail data, such as 
provided by MCI's TrafficView Server 64, and priced 
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call detail data and reports, such as provided by 
MCI's StarODS Server 63 in a variety of user 
selected formats. 

All reporting is provided through a 
Report Requestor GUI application interface which 
support spreadsheet, a variety of graph and chart 
types, or both simultaneously. For example, the 
spreadsheet presentation allows for sorting by any 
arbitrary set of columns. The report viewer may 
also be launched from the inbox when a report is 
selected . 

A common database may be maintained to 
hold the common configuration data which can be 
used by the GUI applications and by the mid- range 
servers. Such common data will include but not be 
limited to: customer security profiles, billing 
hierarchies for each customer, general reference 
data (states, NPA's, Country codes), and customer 
specific pick lists: e.g., ANI ' s , calling cards, 
etc. . An MCI Internet StarOE server will manage 
the data base for the common configuration of data. 

Report management related data is also 
generated which includes 1) report profiles 
defining the types of reports that are available, 
fields for the reports, default sort options and 
customizations allowed; and 2) report requests 
defining customer specific report requests 
including report type, report name, scheduling 
criteria, and subtotal fields. This type of data 
will be resident in an Inbox server database and 
managed by the Inbox server. 

The Infrastructure component of the nMCI 
Reporting system includes means for providing 
secure communications regardless of the data 
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content being communicated. The nMCI Interact 
system security infrastructure includes: 1) 
authentication, including the use of passwords and 
aigital certificates, 2, public key 
such as employed by a secure sockets layer <SSL) 
encryption protocol; 3) firewalls, such as 
oescribed above with reference to the network 
architecture component; and 4, non- repudiation 
techniques to guarantee that a message °««»»"^ 
from a source is the actual identified sender. One 
technique employed to combat repudiation includes 
».. of an audit trail with electronically srgned 
one .way message digests included with each 

transaction. 

Another component of the nMCI Interact 

infrastructure includes order entry, which is 
supported by the Order Entry ("StarOE") serve ^ 

• „ foa.ures to be oraerea 
The general categories of features 

include: 1) Priced Reporting; 2) Real -time 
Reporting; 3) Priced Call Detail; 4) Real Time Call 
oefail; I Broadband SNMP Marming; S) Broad band 
Reports; 7) Inbound RTM; 8) Outbound RTM; 9 Toll 
Fre e Network Manager; and 10) Call Manager. The 
order entry functionality is extended to 
additionally support 11) Event Monitor; 2) Service 
inquiry; 13) Outbound Network Manager; 14) 
Portfolio; and, 15) Client View. 

The self -monitoring infrastructure 
component for nMCI Interact is the employment of 
mid - range servers that support SUMP alerts at the 
hardware level. In addition, all software 
processes generate alerts based on process health, 
connectivity, and availability of resources (e.g., 
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disk usage, CPU utilization, database 
availability) . 

The Metrics infrastructure component for 
nMCI Interact is the employment of means to monitor 
throughput and volumes at the Web servers, 
dispatcher server, application proxies and mid- 
range servers. Metrics monitoring helps in the 
determination of hardware and network growth. 

To provide the areas of functionality 
described above, the client tier 50 is organized 
into a component architecture, with each component 
providing one of the areas of functionality. The 
client -tier software is organized into a 
"component" architecture supporting such 
applications as inbox fetch and inbox management, 
report viewer and report requestor, TFNM, Event 
Monitor, Broadband, Real-Time Monitor, and system 
administration applications. Further functionality 
integrated into the software architecture includes 
applications such as Outbound Network Manager, Call 
Manager, Service Inquiry and Client View. 

The present invention focuses on the 
client and middle- tier service and application 
proxy components that enable customers to request, 
specify, customize, schedule and receive their 
telecommunications network call detail data and 
account information in the form of reports that are 
generated by the various back-end application 
servers. Referred to herein as "StarWRS" , this 
WWW/Internet Reporting System 200, as shown in 
Figure 7, comprises the following components and 
messaging interfaces : 

1) those components associated with the 
Client GUI front end including a report requestor 
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client application 212, a report viewer client 
application 215 and, an Inbox client application 
210 which implement the logical processes 
associated with a "Java Client", i.e., employs Java 
5 applets launched from the backplane (Figure 3) that 

enable the display and creation of reports and 
graphs based on the fields of the displayed 
reports, and, allows selection of different 
reporting criteria and options for a given report; 
10 and, 

2) those middle- tier server components 
enabling the above-mentioned reporting 
functionality including: a Report Manager server 
250 a Report scheduler server 260, and an Inbox 
Server 270. Also shown in Figure 7 are the system 
Order Entry client application 280 and a 
corresponding Order Entry Server 285 supporting the 
StarWRS reporting functionality as will be 
described. 

Each of these components will now be 
described with greater particularity hereinbelow. 

The Report Manager ( "RM" ) server 250 is 
an application responsible for the synchronization 
of report inventory with the back-end "Fulfilling" 
servers 300; retrieval of entitlements, i.e., a 
user's security profiles, and report pick list 
information, i.e., data for user report 
customization options, from the system Order Entry 
server 280; the transmission of report responses or 
messages to the Dispatcher server 26 (Figure 7); 
the maintenance of the reporting databases; and, 
the management of metadata used for displaying 
reports. In the preferred embodiment, the RM 



20 



25 



30 



-32- 



SUBSTITUTE SHEET (RULE 26) 



BNSDOCID: <WO 9916207A1_I_> 



WO 99/16207 



PCT/US98/20148 



server 250 employs a Unix daemon that passively 
listens for connect requests from the GUI client 
applications and other back-end servers and deploys 
the TCP/IP protocol to receive and route requests 
and their responses. Particularly, Unix stream 
sockets using the TCP/IP protocol suite are 
deployed to listen for client connections on a 
well-known port number on the designated host 
machine. Client processes, e.g., report requestor 
212, wishing to submit requests connect to RM 250 
via the dispatcher 26 by providing the port number 
and host name associated with RM 2 50. Request 
messages received by the RM server are translated 
into a "metadata" format and are validated by a 
parser object built into a report manager proxy 
250' that services requests that arrive from the 
GUI front-end. If the errors are found in the 
metadata input, the RM 250 returns an error message 
to the requesting client. If the metadata passes 
the validation tests, the request type will be 
determined and data will be retrieved in accordance 
with the metadata request after which a response 
will be sent back to the requesting client. 

As shown in Figure 7, interface sockets 
252 are shown connecting the Dispatcher server 4 6 
and the RM server 250 and, other socket connections 
254, 256 provide the interface between the RM 250 
and respective middle tier systems 400 and 500. 
For instance, fulfilling system 400 receives 
requests for a customer's priced billing data 
through a publish- and- subscribe Talarian smart 
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socket messaging interface 3.50 providing guaranteed 
message delivery of messages from the Report 
Manager. It should be understood that the RM 250 
server can manage reporting data for customer 
presentation from other middle-tier and back-end 
legacy systems including, e.g., TrafficView, 
Broadband, Service Inquiry, etc. in order to 
present to a customer these types of network 

management data. 

The report manager server additionally 
utilizes a database 258, such as provided by 
Informix, to provide accounting of metadata and 
user report inventory. Preferably, an SQL 
interface is utilized to access stored procedures 
used in processing requests and tracking customer 
reports. A variety of C ++ tools and other tools 
such as Rogue wave' s 'tools .h++ are additionally 
implemented to perform metadata message parsing 
validation and translation functions. 

The Report Manager server 2 50 
additionally includes the scheduling information, 
however, a report scheduler server component passes 
report requests to the back-end fulfilling systems 
4 00, 500 at the scheduled times. 

The Report Scheduler ("RS") sdrver 
component 260 is a perpetually running Unix daemon 
that deploys the TCP/IP protocol to send requests 
to the back-end fulfilling servers 400, 500, and 
receive their responses. More particularly, the RS 
server 260 is a Unix server program designed to 
handle and process report requests to the 
fulfilling servers by deploying Unix stream sockets 
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using the TCP/IP protocol suite, and sending the 
report request to client connections on a 
well-known port number on the designated host 
machine. As shown in Figure 7, interface socket 
connections 264, 266 are shown interfacing with 
respective back end servers 400 and 500. In the 
case of priced billing data from a StarODS 
fulfilling server 400, report requests are 
published by the RS server 260 to a pre-defined 
subject on the Talarian Server. When handling 
other incoming messages published by back end 
servers using Talarian SmartSockets 4.0, another 
daemon process is provided that uses Talarian C++ 
objects to connect their message queue and extract 
all messages for a given subject for storage in a 
database table included in database 263. Each 
message includes the track number of the report 
that was requested from the fulfilling server. 

From the report scheduler interface, the 
user may specify the type of reporting, including 
an indication of the scheduling for the report, 
e.g., hourly, daily, weekly or monthly. For priced 
data the user has the option of daily, weekly, or 
monthly. For real-time, or unpriced data, the user 
has the option of hourly, daily, weekly or monthly. 
The report scheduler interface additionally enables 
a user to specify a page or E-mail account so that 
a respective page or e-mail message may be sent to 
indicate when a requested report is in the Inbox 
server 270 . 
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As shown in Figure 7, the report 
scheduler server 260 interfaces directly with the 
Report Manager server 250 to coordinate report 
request processing. The respective report 
management and scheduling functions could be 
performed in a single server. 

The Inbox Server component 270 serves as 
the repository where the completed user report data 
is stored, maintained, and eventually deleted and 
is the source of data that is uploaded to the 
client user via the dispatcher over a secure socket 
connection 272. It is also a Unix program that is 
designed to handle and process user requests 
submitted in metadata format using an Informix 
database. Once report results are received from 
the StarODS 400 and TVS 500 and any other middle 
tier or fulfilling servers, the Inbox server 270 
requests the metadata from the Report Manager 
server 2 50 as indicated by the socket connection 
272 in Figure 7. The metadata is stored in the 
Inbox server database 273 along with the report 
results. Thus, if the metadata is required to be 
changed, it will not interfere with the information 
needed to display the reports contained m the 
Inbox. Additionally, as shown in Figure 7, the 
Inbox server interfaces with the report scheduler 
to coordinate execution and presentation of 
reports . 

The StarOE server 280 is the repository 
of user pick lists and user reporting entitlements 
as shown in database 283. Particularly, it is 
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shown interfacing with the Inbox server 270 and 
report scheduler servers 260. The Report Manager 
does not interface with or include metadata for 
StarOE. It will, however, include information in 
the report metadata that will tell the Report 
Requestor it needs to get information (i.e., Pick 
Lists) from StarOE server 285. Particularly, as 
shown in Appendix A, the StarOE server supports 
pick lists for the selection of priced data based 
on the following list: Date, Time (e.g., provided 
in GMT offset), ID Accounting Code (IDACO/Supp 
code, Access Type, Corp ID, Service Location 
w/Service Location Names, Bill Payer w/Bill Payer 
Names, 8XX Number, City, State/Province, Numbering 
Plan Area (NPA) , NXX (Exchange code where N=2-9 and 
X=0-9) , and Country Code. 

A common database is maintained to hold 
the common configuration data which can be used by 
the GUI applications and by the mid- range servers. 
Such common data will include but not be limited 
to: customer security profiles, billing hierarchies 
for each customer, general reference data (states, 
NPAs , Country codes), and customer specific pick 
lists: e.g., ANIs, calling cards, etc.. 

With regard to the front -end client GUI 
components, the above-mentioned Inbox client 
application 210 functions as an interface between 
the client software and the Inbox server 270 for 
presenting to the customer the various type of 
reports and messages received at the Inbox 
including all completed reports, call detail, 
alarms, and news. Preferably, the messages for the 
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user in the inbox is sorted by type (e.g., report, 
call detail, alarms) and then by report type, 
report name, date, and time. 

Particularly, the Inbox client 
application uses the services of the backplane 
(Figure 3) to launch other applications as needed 
to process report messages. The inbox will also 
use the services of the data export objects to 
provide a save/load feature for inbox messages, 
and, is used to provide a user - interface for 
software upgrade/download control. Inbox messages 
are generated by the versioning services of the 
backplane; actual downloads will be accomplished by 
a request through the inbox. 

In the preferred embodiment, the inbox 
client receives information on multiple threads to 
allow a high priority message to get through even 
if large download is in progress. Typically, the 
browser is configured to allow more than one 
network connection simultaneously, i.e., the 
polling thread on the client uses a separate 
connection to check for new messages, and start a 
new thread on a new connection when a new message 
was detected. In this way, multiple messages may 
25 be downloaded simultaneously. 

The Report Requester application 212 is a 
GUI Applet enabling user interaction for managing 
reports and particularly includes processes 
supporting: the creation, deletion, and editing of 
the user's reports; the retrieval and display of 
selected reports; the display of selected option 
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data; and the determination of entitlements which 
is the logical process defining what functionality 
a user can perform on StarWRS, In the preferred 
embodiment, a Report request may be executed 
5 immediately, periodically, or as "one -shots" to be 

performed at a later time. As described herein, 
the report scheduler service maintains a list of 
requested reports for a given user, and forward 
actual report requests to the appropriate middle - 

10 tier servers at the appropriate time. Additional 

functionality is provided to enable customers to 
manage there inventory, e.g., reschedule, change, 
or cancel (delete) report requests. 

The Report Viewer application 215 is a 

15 GUI Applet enabling a user'to analyze and display 

the data and reports supplied from the StarODS 
fulfilling system 400. Particularly, the Report 
Manager 250 includes and provides access to the 
metadata which is used to tell the Report Requestor 

20 what a standard report should look like and the 

"pick- list" options the user has in order for them 
to customize the standard report. It is used to 
tell the Report Viewer client how to display the 
report, what calculations or translations need to 

25 be performed at the time of display, and what 

further customization options the user has while 
viewing the report. It additionally includes a 
common report view by executing a GUI applet that 
is used for the display and graphing of report data 

30 and particularly, is provided with spreadsheet 

management functionality that defines what 
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operations can be performed on the spreadsheet 
including the moving of columns, column hiding, 
column and row single and multiple selection, 
import and export of spreadsheet data, and print xng 
of spreadsheet, etc. It is also provided with 
report data management functionality by defining 
what operations can be performed on the data 
displayed in a spreadsheet including dynamic 
operations as sorting of report data, sub- totaling 
of report data, etc.. Furthermore, the report 
viewer 215 interprets metadata; and, communicates 
with the Backplane (Figure 4) . The report viewer 
application 215 additionally accepts messages 
telling it to display an image or text that may be 
passed by one of the applications in lieu of report 
data (e.g., Invoice, Broadband report, etc.) 

All reporting is provided through the 
Report Viewer interface which supports spreadsheet, 
a variety of graphic and chart types, or both types 
simultaneously. The spreadsheet presentation 
allows for sorting by any arbitrary set of columns. 
The report viewer 215 is launched from the inbox 
client 210 when a report is selected and may also 
be launched from the inbox when a report is 
selected. 

By associating each set of report data 
which is uploaded from the Inbox server 270 with a 
-metadata" report description object, reports may 
be presented without a report- specif ic presentation 
code. At one level, metadata descriptions function 
like the catalog in a relational database. 
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describing each row of a result set returned from 
the middle tier as an ordered collection of 
columns. Each column has a data type, a name, and 
a desired display format, etc. Column descriptive 
information will be stored in an object, and the 
entire result set will be described by a list of 
these objects, one for each column, to allow for a 
standard viewer to present the result set, with 
labeled columns. Nesting these descriptions within 
one another allows for breaks and subtotaling at an 
arbitrary number of levels. The same metadata 
descriptions may be used to provide common data 
export and report printing services. When extended 
to describe aggregation levels of data within 
reporting dimensions, it may be used for generic 
rollup/drilldown spreadsheets with " j ust - in - time" 
data access. 

The metadata data type may include 
geographic or telecommunications - specific 
information, e.g., states or NPAs . The report 
viewer may detect these data types and provide a 
geographic view as one of the graph/chart types. 

Referring now to Figure 8, there is shown 
the high-level logical approach of the StarODS data 
management system 400 integrated with the StarWRS 
component 200 of the nMCI Interact architecture. 
Generally, the data management system 400 of the 
invention, referred to herein' as "StarODS" , 
provides customers with priced reporting data 
pertaining to telecommunications services. 
Although the description herein pertains to priced 
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billing data, it should be understood that the 
principles described herein could apply to any type 
of reporting data. Through StarWRS web -based 
reporting, the StarODS system provides priced 
reporting data and implements a DataMart approach 
for maintaining the data used for customer 
reporting. StarODS stores and incrementally 
processes customer's priced data included in call 
detail records, and loads this processed data in 
Data Marts. From these data marts customer's 
priced reporting data may be provided to customers 
on a daily basis via the StarWRS reporting system. 

For priced reporting data, report 
categories from which a variety of reports can be 
generated include: a) Financial category - for 
providing priced data reports relating to longest 
calls, most expensive calls, Off Peak Calls, 
payphone report, usage summary, calling card 
summary, and area code summary for Toll Free, VNET , 
Vision, and CVNS customers; b) Marketing category - 
for providing priced data reports relating to 
country code summary, state summary, frequent 
numbers, frequent area code summary, frequent 
state, and frequent cities; c) Telecommunications 
category - for providing priced data reports 
relating to call duration summary, IDACC/Supp Code 
Summary and Call Access Summary for Toll Free, 
VNET, Vision, CVNS customers; d) Call Center report 
category- for providing priced data reports 
relating to most active toll free numbers. Hourly 
Distribution, Day of Week Distributions, state 
summary, and country code summary for their Toll 
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Free, VNET , Vision, CVNS customers; e) Monitor 
Usage - for providing priced data reports relating 
to longest calls, most expensive calls, most active 
calling card and most active toll free numbers for 
their Toll Free, VNET, Vision, CVNS customers; f) 
Analyze Traffic - area code summary, country code 
summary, state summary, range summary, city 
summary, frequent numbers, payphone report, usage 
summary, calling card summary, IDACC/Supp Code 
Summary, Day of Week Distributions, Hourly 
Distribution, Call Access Summary and review calls ; 
and, a g) Check Calling Frequencies category - for 
reporting on frequent numbers, frequent area code, 
frequent country codes, frequent state and frequent 
cities . 

Figure 8 illustrates the primary 
components implemented in the StarODS priced 
reporting data management component 400. As shown 
in Figure 8, a first traffic feed 405 provides raw 
call detail records from external network switches, 
translates and sorts the data into billable records 
for input into two systems: a Commercial Billing 
system ("NCBS") mainframe server process 410 for 
pricing the records at tariff for customers 
subscribing to, e.g., MCI's VNET and Vision 
telecommunications products; and, a toll-free 
billing server process 420 for pricing the records 
at tariff for customers subscribing to toll-free 
telecommunications products. A common data gateway 
component 430 including a mainframe extract process 
435 and a data harvesting process 440 receives 
these inputs on both a daily and monthly basis for 
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processing. Particularly, the mainframe extract 
process 435 creates a selection table including all 
subscribing customers, compresses files for 
transmissions and extracts priced reporting records 
from the runstreams. The harvesting process 440 is 
responsible for performing data validations, 
filtering, data translations, data grouping, data 
routing, and data logging functions. According to 
a dimension table based on data within selected 
BDRs , the harvesting process applies business rules 
to the data, cleanses the data, transforms the 
data, creates load files for DataMarts and 
compresses files for storage in the DataMarts . The 
harvesting component 440 may additionally perform 
an aggregation function for supporting long term 
storage and rapid access of data for customer 
reporting, and performs trigger actions/events 
based on predefined criteria. 

Additionally, as shown in the Figure 8, 
other external systems and applications may 
interface with the common data gateway component 
430 including: Cyclone Billing system 422a and 
Concert Virtual Network Services 422b which provide 
additional billing detail records; and, a calling 
area database 425 which provides geographical 
reference information, i.e., identify city, state 
and country information. 

After the data has been processed in the 
Harvesting component 44 0 it is input to an 
operational data store component ("ODS") 450 that 
stores the billing detail records and dimension 
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tables as a data model. This ODS layer 450 is 
comprised of all data harvested from all 
applications in the data harvesting layer 430, and 
feeds report - supporting DataMarts 470 in a manner 
which supports customized data access. The 
Datamarts may be engineered to pre-process data, 
create aggregates, and otherwise perform 
transformations on the data prior to DataMart 
loading 465 in order to implement a defined data 
model, e.g., star schema key structures, fact and 
dimension tables depicted as block 460. In the 
preferred embodiment, as shown in Figure 8, the 
Operational Data Store 450 includes multiple 
datamarts 470 each for storing and retrieving daily 
and monthly priced data on a periodic basis. It 
primarily is responsible for hosting highly current 
data, typically at least 72 hours old.. In 
accordance with customer - reporting needs, data 
marts 470 are partitioned in accordance with 
partitioning schemes which, in the invention, is 
based on customer- ID. Particularly, each DataMart 
is engineered for servicing specific customers or 
specific product sets, as well as engineered for 
the specific requirements of the customer/product 
such as high insert activity, heavy reporting 
requirements, etc. As data is volatile and 
changing and may not produce consistent results for 
the same query launched at multiple times, ODS is 
engineered for high performance through appropriate 
storage technologies and parallel processing. 
Although not shown, a common data warehouse is 
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provided in this ODS layer that is responsible for 
performing storage, retrieval and archiving of 
data, typically of relaxed currency (e.g., more 

than 24 hours) and is targeted at trend analysis 
5 and detection. In the preferred embodiment, the 

datamarts utilize an Informix database in a star 

topology. 

Particularly, as illustrated in Figure 9, 
the data model 459 is one component comprising the 
, 0 priced reporting data store. In the preferred 

embodiment, the data model of StarODS is a 
dimensional or "star schema" model, including a 
central fact table multiply joined to a number of 
attendant tables known as dimensions. The 
relationships between the fact table and the 
dimensional tables are either enforced through 
keys, which may be generated, or as lookup codes. 
As shown in Figure 9, the central fact table 461 
referred to herein as "Perspective Base." provides 
access to a collection of attributes or facts 
concerning a call. The dimensional tables include 
the following: an Access Termination table 462 
comprising data indicating whether a call was 
charged to recipient (inbound) or originator 
(outbound) ; an Access Type table 464 comprising 
data indicating the type of access (for outbound 
calls) or egress (for inbound calls) 
characteristics of a call, a Billing Corp table 466 
comprising data indicating the hierarchical status 
30 of a customer for the purposes of billing charges 

for products and features; a Toll Free Number table 
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468 comprising data indicating any dialed number in 
which the three digits following the country code 
(1 for USA) is currently either 800 or 888; a 
Product Type table 469 comprising data indicating 
the product for which ■ services are bundled for the 
purpose of invoicing; a GMT table 471 comprising 
date and time data adjusted to the Greenwich Mean 
Time Zone; a LST table 473 comprising date and time 
data adjusted to the local MCI switch which 
permitted access to the MCI network; an Orig_Geo 
table 476 comprising data indicating the geographic 
characteristics of a call's origination; a Term_Geo 
table 477 comprising data indicating the geographic 
characteristics of a call's termination; a Report 
Geo table 478 comprising data indicating the 
geographic characteristics of a call's origination 
or termination; an Idacc table 479 comprising data 
indicating a customer's defined id and/or 
accounting code; a Data Stream table 481 comprising 
data relating to the line speed characteristics of 
a data (non- voice) call; a Pay Phone table 482 
comprising data denoting calls originating from a 
payphone; a Usage table 4 83 comprising data 
indicating the geographic attributes of a call 
which affect Tariff rates; an EVS Product table 4 84 
comprising data representing Enhanced Voice 
Services products; a Directory Assistance table 486 
comprising data indicating those calls requesting 
Directory assistance; a Range table 487 comprising 
data indicating distance bands a call may fall 
into; an NCR table 4 88 indicating Network Call 
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Redirect calls; a Cell Phone table 489 comprising 
cellular call characteristics data; a VOS table 491 
indicating Voice Operator Services calls; a 
Conference Call table 492 having data pertaining to 
characteristics of conference calls; a Cross Corp 
table 493 comprising data indicating inbound cross 
corporate routing of calls; a Currency table 494 
indicating unit of currency for call prices; a card 
table 496 comprising data for billing calls to a 
location that may not be the one which originated 
the call an NCT table 497 comprising data 
representing Network Call Transfers; an Amount 
Range table 498 indicating call usage ranges based 
upon amounts; and, a Duration Range table 499 
indicating call usage durations based on amounts. 
This star schema model is optimized for decision 
support and the retrieval of large amounts of data. 
Appendix H provides the data attributes of each of 
these dimension tables. As known, in the 
dimensional model, the grain of data stored in the 
fact table determines what level of data can be 
drilled down into. It should be understood that 
the grain of the data stored in the Perspective 
Base table is at the singular call level. 

As described herein, from the data 
included in these data marts, one-time or recurring 
priced data reports are available for reporting 
through the NMCI Interact StarWRS reporting system 
200. 

Additionally, referring back to Figure 8 
there is provided a Decision Support Server ("DSS") 
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reporting engine component 475 that performs the 
following functions: 1) receives various customer 
report requests from the StarWRS GUI Report 
Requestor component and accordingly generates 
database queries; 2) routes the query to the 
appropriate data marts 470, data warehouse or 
operational data store; and, 3) responds to the 
requestor with a formatted result set. The DSS 
server 475 may also perform cost estimation, agent 
scheduling, workflow broadcasting interface, and 
transaction logging functions. In the preferred 
embodiment, the DSS 475 is a cluster of DEC 
(Digital Equipment Corp.) UNIX 8400 servers running 
Information Advantage® software accessing an 
Informix database, e.g., Informix Dynamic Server 
V.7.3. database product, distributed across 
multiple Data Marts. 

In accordance with the invention, the 
primary function of the DSS 475 is to generate 
priced billing report data in accordance with the 
customer's request which is received from the 
StarWRS reporting component as a metadata message. 
To accomplish this, the DSS interfaces with two 
StarWRS systems: Report Manager 250, and Inbox 270, 
as shown in Figure 8. The Report Manager/Scheduler 
formats the customer's request in accordance with a 
defined set of rules and sends a metadata request 
message to the DSS. The DSS 475 reads the 
customer's metadata descriptions of the type of 
priced data report requested by a customer, 
translates the metadata into database queries, and 
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implements commercial off-the-shelf ("COTS") tools 
such as information Advantage's Decision Suite™ to 
generate SQL queries, and run the queries against 
the data in the DataMarts . Afterwards, the query 
results are formatted- by a formatter process into a 
form readable by StarWRS report viewing components, 
and the completed reports are transmitted to the 
directory of the customer's Inbox, e.g., via FTP. 

In the preferred embodiment, a publish - 
and- subscribe communications tool such as Talarian 
SmartSockets™ messaging middleware is used to 
coordinate report requests transmitted from the 
StarWRS report Manager to DSS, and report 
completion notification from DSS to the StarWRS 
Report Manager. The Report Manager formats the 
customer's request in accordance to a defined set 
of rules and sends the request to the DSS as a 
Talarian message with the Report Manager 250 
maintaining the Talarian Sender program, and the 
Decision Support Server 475 maintaining the 
Talarian Receiver program. Messages are sent with 
guaranteed message delivery ( "GMD" ) thus assuring 
all request data sent by RM is received by the DSS. 
As known, Talarian messaging middleware defines a 
message as types and subjects. A message type is a 
structure that defines the format of the message. 
Message subjects are subsets of message types and 
describe messages by which Talarian receivers can 
subscribe. Conversely, message subjects describe 
messages by which Talarian senders publish. 
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As depicted in greater detail in Figure 
10(a), a Report Manager/DSS application programming 
interface "API" 480 is provided whereby the RM 
server 250 publishes the message to the Decision 
Support Server in response to its receipt of a 
report request. Subsequently, the DSS 475 returns 
a "Message Received" message. When the DSS has 
processed the request, it publishes the message to 
the RM 2 50 with the name and location of the report 
file or an error message to the Report Manager, via 
an "NRL" metadata message as described herein. 

Figure 10(b) illustrates an DSS/Report 
Manager application programming interface "API" 
485. In the preferred embodiment, all return 
messages are persistent. Thus, as shown in Figure 
8 the DSS incorporates a Talarian message queue 490 
operating on a First - In - First -Out (FIFO) basis. If 
the DSS is unable to establish the connection with 
Talarian, or there is an error in transmission, the 
DSS queues all messages, and continues to retry 
until a successful send is executed. 

Similarly, a DSS/Inbox API is provided to 
manage FTP file transmissions including: error 
handling, retry logic, and the ability to maintain 
the file name and location of where report files 
are stored. Particularly, the DSS/Inbox API sends 
the report file to the inbox (Figure 8) . If the 
DSS has generated an error condition, and the 
report is unable to be generated, an error message 
will be sent to the inbox in place of. the report 
file. In either case, a return message will be 
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delivered to the DSS/Report Manager API 485 
indicating a successful or unsuccessful generation 
and transmission of the report file. 

More particularly, as shown in Figure 
5 12(a), an RTServer process 377 is provided for 

maintaining connections, ensuring guaranteed 
message delivery, and tracking the success of all 
messaging operations. As the Report Manager 
interfaces with multiple systems, the RTServer 377 
10 processes are located in the RM. The DSS is 

provided with RTClient processes 377a, b that 
provides the API to RTServer: one RTClient 377a for 
providing the API to Report Manager for receiving 
messages; and. a second RTClient 377b for providing 
the API for the NRL. However, it should be 
understood that other ODS boxes can have one 
RTClient. The RM and Arbitrators 360a, b use the 
GMD feature of Talarian to deliver messages. 

RM/Inbox communication is not affected by outages 
of ODS server as the arbitrator and ODS 
communication is independent of RM/Inbox 

communication. 

In the preferred embodiment, the DSS 
architecture is transparent to the Report Manager 
2 5 which publishes Talarian messages to which the DSS 

will subscribe. In addition to the tokenized 
character string request message which specifies 
report type, filters, and any customer request- 
specific information, RM server provides additional 
30 fields as part of the Talarian request message 

including: a Corp_ID, Priority, and RequestlD. 
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Corp_ID allows the DSS to route the request to the 
appropriate data store without having to invoke a 
parser. Data are partitioned on Corp__ID in the ODS 
database warehouse. Request__id is used to send 
back an ARDA failure message, in the event of an 
invalid message. The Priority field allows DSS to 
pickup the next high priority request from a queue 
of non-processed requests, without invoking the 
parser. 

Figure 11(b) illustrates the 
implementation of the COTS Information Advantage® 
Interface Object ("IAIO") 372, which is a process 
running in the DSS 475 for performing the following 
functions: 1) publishes and subscribes Talarian 
messages to Report Scheduler; 2) parses the request 
metadata ARD (Add Report Definition) message; 3) 
publishes an ARDA (Add Report Definition 
Acknowledgment) ; 4) populates a request table 390 
with total, sub- total and sort information 
according to the received report request; 5) 
transforms the ARD tokens from the metadata request 
into an overlay file 392 which is a text file that 
is submitted to IA's Decision Suite™ process to 
generate the corresponding SQLs; 6) updates a 
Request Status table 391 with appropriate status, 
e.g., process complete, failed, in progress, etc.; 
and, 7) if a failure occurs, it updates an error 
log (hot shown) . 

More particularly, in view of Figure 
11(b), ARD metadata request messages are received 
into the ODS system via arbitrator processes 360a, b 
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which are responsible for routing the request 
message to the appropriate ODS database according 
to a Corp/ODS mapping table 365. Report Manager 
publishes a single message subject "Arbitrator- 
having the above-mentioned request, Corp_ID, and 
Priority field information. Report Manager uses a 
round robin message delivery mechanism complemented 
by Talarian's GMD to publish messages to the 
subject Arbitrator 360a, b. The arbitrator extracts 
the Corp_ID field from the message and maps the 
Corp_ID to corresponding ODS DataMart in the table 
365 it maintains. The arbitrator then republishes 
the message with the ODStt . As shown in the Figure 
1Kb), a second arbitrator process 360b is provided 
to assure fail -over capabilities. 

in Figures 11(a) and 1Kb), a Talarian 
receiver, referred to herein as a Talarian 
interface Object ( "TIO" ) 370, is a process that 
receives the Talarian message, manages the GMD 
functionality, and posts updates to the request 
table 39 0 and request status table 391. As shown 
in Figure 1Kb), the TIO receivers 370 subscribe to 
a subject <<ODS#.» The receiver inserts the message 
received from the arbitrator into the request table 
390 and request status table 391 along with the 
priority, timestamp and status fields. The request 
status table resides on the ODS database and the 
messages are stored in the queue to provide 
queuing, log and tolerance from the failures. To 
determine the pending messages to be processed, 
status field and history_stat flags are used. 
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Appendix "I" illustrates the contents of the ODS 
Request table 390 and Request Status tables 391, 
which are part of the ODS database. 

In the preferred embodiment, the tables 
provided in Appendix I include: an 

"informix" . request table 390 (Figure 11(a)) which 
is the table maintained for the purpose of holding 
specific report request information from the 
received ARD message, and, an "informix" . req_status 
for holding status of DSS processes for the current 
request . 

Thus, for the example ARD message 
provided in Appendix I, the request table 390 will 
be populated to include: a "requested," which is 
the unique identifier for the request; a 
"msg_desc," representing a copy of the ARD message; 
"unique_f name, " which is the unique name assigned 
to each request to enable tracking of individual 
report requests and is additionally assigned to the 
report returned to the report manager; a 
"report_dir" indicating the location of the report 
that Decision Suite™ generates (which may be a tab 
delimited report file) ; "forma t_dir" indicating the 
location where the report formatter generates 

(comma delimited file) ; "inbox_dir" indicating the 
location on the Inbox (Report Manager) where the 
report is sent; "inbox_f size" indicating the size 
of the file; "entpid," indicating the Enterprise id 
which may consist of one or more corporate id f s; 

"userid" which is an identifier assigned to each 
user of the system; "s tdrptid" which identifies each 
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report and is similar to column id's but on the 
report level; "userptid" which is the user-assigned 
identifier for a report request; "compress" having 
possible values = yes. .-2- - no indicating if a 

report is to be compressed, e.g., using a standard 

zip routine; "threshold" defining the number of 
lines that shall appear on the report; "totalmode" 
which defines how the report shall be totaled, 
subtotaled as indicated by possible values '0« 
total, No subtotal; ■!• = Only Subtotal; '2- = Only 
Total; '3- = Total and Subtotal; "nrl_totals" 
indicating the formatter to total the columns 
specified in the "*.hdr" file. These columns are 

i_4.„4-,t flan = 'v' in a column 
numeric and have a subtotal flag y 

id table; " forma t_columns" which define derived 
columns on which percentages are to be calculated;. 
"error_code" for indicating parser failure or 
system failure. If it's a parser failure 
condition, the code is returned to Report Manager; 
«error_desc" indicating the error description; and, 
"r P mgr_columns" which are the columns sent to the 
DSS by Report Manager. The formatter checks thxs 
list against the list in the .hdr file. 

Similarly, the Request_Status table 391 
provided in Appendix I is populated to include the 
status of the different processes including: 
-Requested," i.e., the unique identifier for the 
request, "Priority," e.g., having a value of -1." 
for example. meaning adhoc; a "timestamp" which is 
the Informix Date Time that will be used when two 
or more messages have same priority; and "Status" 
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which is a char message including the following 
status fields: "new__message" indicating that a new 
message has arrived, yet to be processed; "in_IAIO" 
status indicating that the message is being 
processed by interface process IAIO; 
"parser„f ailed" status indicating an Invalid 
message from RM. NRL process sends a ARDA error 
message; "parser_success". status indicating that 
the message from RM is a valid message. NRL process 
would send a ARDA message to RM; "IAIO_complete" 
status indicating that the report has been 
generated and directory and file name fields are 
modified. Formatter can pick up this message; 
"IAIO_f ailed" status indicating that IA has failed 
to generate a report, i.e., an error has occurred 
generating a report; "in_f ormat ter" status 
indicating that the formatter is converting the 
text file generated by IA to a comma delimited 
format. The formatter may also, if required, does 
the percent (%) calculations, e.g., subtotals etc.; 
"forma t__success" status indicating that the 
formatter successfully completed translation of the 
file. It also populates the inbox file name, inbox 
file directory, nrltotal (optional) fields in the 
table; "forma t_f ailed" status indicating that the 
formatter failed to translate the text file 
generated by IA; "in__f tp" . status indicating that 
the ftp process is currently sending the file to 
inbox; "f tp_success" status indicating that the 
file generated by formatter is ftp'd to inbox; 
"ftp_f ailed" status indicating that the formatted 
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file could not be ftped to inbox; " in_NRL" status 
indicating that the NRL process is trying to send 
either ARDA message or NRL message to RM; 
"NRL_sent" status and "ARDA- sent" status indicating 
5 that the respective NRL or ARDA message has been 

sent to RM. Each DSS process updates the request 
status table as it processes. 

A further "history_stat" field may be 
provided in the requests tatus table 391 having a 
,0 value, e.g., 'A' (Active) indicating that the 

record needs to be processed, or, indicating 
<H' (History), when the record is no longer active 
and needs to be archived in a separate database set 
up for archival purposes (not shown) . 

As further shown in Appendix I, there are 
two more tables that are defined for DSS sorting 
and formatting processes: a Column ID Table, and a 
Translation table which are tables configured for 
the formatter process, as will be described. 

As further shown in Figure 11(b), in 
operation, each Information Advantage® Interface 
Object ("IAIO") 372a,b,..n reads the status table 
391 for new entries. When a new entry is posted, 
it invokes a parser process 393, and invokes the 
information Advantage® SQL generator engine which 
retrieves the requested data from the database, and 
updates the status table 391. 

Particularly, the Decision Suite™ tool 
receives the overlay file (Figure 11(a)) and 
30 performs the following functions: 1) generates SQL; 

2) submits the SQL to the appropriate datamart (ODS 
database); 3) generates a Report file with a * . txt 
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extension; 4) updates Request Status table 391 with 
appropriate status; and, 5) if a failure occurs, 
updates the error log. Following generation of the 
*txt file, a sort process is invoked to perform the 
following functions: 1) reads the Request table 390 
for column (s) on which to sort the Report; 2) reads 
the * . txt file; 3) sorts the *.cxt file and 
generates two files: i. a file with a *.hdr 
extension which file contains the header 
information, consisting only of only column id's, 
and, ii. a file with a *. data extension which file 
contains sorted data provided in the * . txt file and 
is the body of the Report; 4) it further updates 
the request status table with a 'success' or 
'failure' code; and, 5) if a failure occurs, 
updates the error log. 

As further shown in Figure 11 (b) , 
continuously running FTP, NRL and ARDA processes 
are provided to take appropriate actions in 
accordance with the request status table entries. 
For example, an FTP process 37 8 performs the 
following functions: 1) reads the status table 391 
for entries ready to be sent to the Inbox and FTP'S 
the .csv or .txt to the inbox 270; 2) Determines 
success or failure of file transfer; 3) Updates the 
Request Status table 391; and, if a failure occurs, . 
updates an error log. 

The NRL (Notification of Report Location) 
process 382 performs the following functions: 1) 
reads the Request Status table 391 for any success 
status or failure of any process; 2) Invokes a 
receiver process with appropriate status and file 
location populated in the NRL; and, 3) If failure 

-59- 



SUBSTITUTE SHEET (RULE 26) 



PCTAJS98/20148 

WO 99/16207 



10 



15 



20 



25 



30 



occurs, updates the error log. Particularly, 
should an error occur in any of the DSS processes, 
an error log is updated. Error log directories may 
be delineated by process and day of week. Each new 
error generated by the same process in the same day 
appends the log with the new message. In either 
event, the NRL process returns the NRL message to 
Report manager indicating the status and location 
of any generated files. 

As further shown in Figure 11 (b) , an ARDA 
process 383 reads the status table 391 for parser 
failures. Should the parser fail due to 
insufficient or missing data, ARDA process will 
return an ARDA message to the Report Manager with 
the appropriate error code. In particular, the 
types of conditions that result in error messages 
being sent to the report manager and/or local log 
include: i) when the request message received from 
the Report Manager can not be parsed due to bad 
data or invalid format; ii) when the SQL can not be 
generated due to invalid request format or 
parameters; iii) system or process failure; iv) 
cannot query database due to a database failure; 

Q t C 

For Priced Reporting, the StarWRS report 
requestor functionality is invoked. Particularly, 
the end-to-end process 600 from a priced report 
request to report delivery is shown in Figure 13(a) 
- 13(c). Specifically, a user first establishes 
communication with the DMZ Web server 44 and logs 
on to the nMCI Interact system by entering the 
user's name and password onto a logon dialog box. 
Then, an application running on the backplane 
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directs a "Validate User Message" common object to 
the StarOE server 280 via the web server and 
dispatcher servers (Figure 3) to direct the StarOE 
server 280 to perform security validation and 
authenticate the user .ID and password. It is 
understood that all communication to the StarOE 
server is via TCP/IP with a Unix process listening 
on a known TCP port. The StarOE server acts as a 
proxy when messages are sent from the Dispatcher 
server 46 and supports synchronous transactions. 
All data and security information is accessed by 
direct queries to a StarOE server database 283, 
such as provided by Informix. Once a user is 
logged on, the Web Server 44 (Figures 3 and 7) 
requests a current list of authorized applications 
from the StarOE server 285. Particularly, a "Get 
User Application Request" message is communicated 
to the StarOE server via the backplane from the 
report requestor which queries the Informix 
database to obtain a list of authorized 
applications, i.e., services, for the user and 
which determines which buttons on the home page are 
active, thus controlling their access to products. 
This information is downloaded by a GUI applet that 
is executed via the Backplane (Figure 4) and 
incorporated into the home page that is presented 
to the user. An exemplary home page screen display 
80 is shown in Figure 5 which provides a list of 
icons 70 representing the possible options 
available to the user according to that customer's 
entitlements. 

The Report Requestor first asks for 
common objects for a user's default timezone, 
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language and currency. The Report Requestor 
objects are invoked to retrieve from StarOE the 
various customer entitlements relating to security, 
geographical hierarchy, billing hierarchy, and 
paging and e-mail notification. 

in response to selection of the Report 
Requestor icon, a display is generated to present 
the reporting options to a user in accordance with 
that user's entitlements as previously determined. 
It should be understood that in the preferred 
embodiment, the icons for applications the user has 
security access to are shown bolded . Thus, for a 
customer subscribing to nMCI Interact Priced 
Reporting, a Priced Reporting icon is automatically 
enabled when the home page appears. 

Thus, upon selection of a Report 
Requestor icon 76 from the home page screen display 
80 of Figure 5, a StarWRS report requestor web page 
is presented to the customer. The backplane object 
allows the user access to the Report Requestor 
front end if the user is so authorized, and a 
client priced reporting application is downloaded 
to the customer who is presented with the Priced 
reporting dialog screen (not shown) , as indicated 
at step 602 in Figure 13(a). It is from this 
screen that the user is presented with priced 
reporting options to view/ retrieve completed 
reports via the StarWRS Inbox, or create a new 
report or, modify an existing Priced call detail 
30 data report. 

Particularly, from the Priced reporting 
dialog screen, the user is enabled to edit an 
existing report maintained in the report manager 
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inventory, generate a new report, copy an existing 
report, or delete an existing report. For example, 
as indicated at step 605 (Figure 13(a)), a user may 
initiate retrieval of the user report list 
containing existing user reports from the RM 
inventory, which process entails invoking the 
Report Requestor to initiate generation of a 
metadata request to download the report inventory 
from RM as indicated at step 610. The Report 
inventory for the specific user is loaded and 
displayed for the user on the user report request 
display screen, enabling the user to select a 
report, as indicated at step 612. Then, at step 
615, the selected report is retrieved from StarWRS 
Report Manager and displayed for the customer. 

Then, as indicated at steps 618 and 620, 
the customer may enter the desired reporting 
options and reporting criteria including: 1) the 
report product including toll-free, MCI Vision, and 
MCI Vnet options; 2) the report category which 
includes options for: analyzing traffic, call 
center, call detail, checking calling frequencies, 
financial, marketing, monitoring usage, and 
telecommunications categories for toll-free, Vnet 
and Vision customers; 3) the report type which 
includes priced call detail data or traffic data 
options; and 4) a report direction and which 
includes inbound, outbound, or both directions. 
Additionally, the user may select the report format 
associated with a reporting category. 

Whether creating a new report or editing an 
existing report, the user is enabled to select 
customization options from successive dialog 
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screens (not shown) that are presented to the user 
showing all the report customization categories for 
building a new report and/or editing an existing 
report. From this screen and related report 
building dialog boxes, all of the initial values 
for retrieving the MetaData, customization options 
and GUI builder options from the report manager 
server 250 necessary to build (edit) a report are 
provided in accordance with the user's 
entitlements. A user may provide the following 
customization and report builder options: general 
customization options; layout customization 
options; access customization options; hierarchy 
customization options; geographic customization 
options; and, notification customization options. 

in performing the report request process, 
as shown in Figure 7, the Report Requestor client 
application 212 gains access to the Metadata stored 
at the Report Manager server 250 through messaging, 
as indicated at step 625. Particularly, as 
hereinafter described, a message generated by the 
Report Requestor in accordance with the user 
request is first received by the report manager 
proxy 250'. In the preferred embodiment, the 
report manager proxy comprises a set of tools in 
the form of reusable objects, preferably written in 
C++ code, or the like. For example, a parser object 
tool is employed to decompose the Metadata messages 
sent by the report requestor 212 to validate the 
message. If errors are found in the Metadata 
input, the RM will return an error message to the 
requesting client. If the Metadata passes the 
validation tests, the request type is then 
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determined and the appropriate service will be 
invoked after which a standard response is sent 
back to the requesting client or and/or fulfilling 
server . 

The Report Manager 250 implements stored 
procedures to translate the message, perform the 
request, and send the information back to the 
Report Requestor 212 which uses the metadata to 
determine what a standard report should look like, 
the customization options the user has, and the 
types of screens that should be used for the 
various options (i.e., single selection, multiple 
selections, etc.) . 

It is understood that the selection of available 
standard template reports is based on the user's 
entitlements . 

The following list provides the types of 
requests that may be initiated by the Report 
Requestor 212 and the responses performed by the 
Report Manager 250: 1) Get/Send report template 
list (GRTL/SRTL) - which request retrieves the list 
of all standard report templates for all products 
and is used only to obtain general report 
information, e.g., report title, description, etc.; 
2) Get/Send report template detail (GRTD/SRTD) - 
which request retrieves the details of a specific 
standard report template; 3) Get /Send user report 
list (GURL/SURL) - which request retrieves the list 
of all user reports for the report format selected 
from a user report table and is used only as a 
request for general report information, e.g., 
report title, status, etc.; 4) Get/Send user report 
detail (GURD/SURD) - which request retrieves the 
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Parameter 


parameter 


Required 1 


Acceptable 
value i_ 


Name . 

Request 


Type 

3 or 4 

characters 


Yes 


Msg acronym 


Data 

oarms... 


Characters 


1 No 





Table 1 
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Table 2 illustrates the interface message 
format returned by the RM server 250. 



Par ame t er 
Name 


Parameter 
Tvpe 


Required 

Yes 


Acceptable 
Value 

Msq acronym 


Response 
Error Code 


Char (4) 
Char (4) 


Yes 


0 = OK or 
error 


Data 

parms... 


Char # 


No 





Table 2 



As shown in Table 2, the response message to 
be returned in Metadata format preferably includes a 
four character message acronym followed by an error 
code A successful request (or a request 
acknowledgment) generates a response with an error code 
of "0". Additional data specific to the response 
follows this error code. If any server receives a 
message which is not known, the response message will 
echo the message acronym back along with an appropriate 

error code. 

Appendix A provides a series of tables 
containing the content for each metadata message- 
request that can be sent by the report requestor 212 
for each of the enumerated user requests, in addition 
to the content of the corresponding metadata message 
responses by the RM server 250. As an example, when a 
user requests a list of all standard report templates 
that can be created for a specified product, category, 
and product type, e.g., toll free unpriced data, an 
example metadata format is as follows: 
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GRTL<PRODUCT=V, DATATYPE=R. DATACAT=P , IO-0> 

where GRTL is the message name, the PRODUCT indicates 
the product type, e.g., V=Vnet, C=CVNS, S^Visxon T= 
toll free, F- Traffic view, etc. DATATYPE mdrcates the 
data type, e.g. Reports, D-c.ll detail. «tc.^ 
DATACAT represents the report category, e.g., P-pnce , 
U=unpriced. 

in the hereinafter described manner, the GRTL 
message is received by the StarWRS proxy server 
filiation 250 • to enable the RM server 250 to perform 
the query into the RM Informix database having the data 
associated with the request. Specifically, after 
selecting the Report Requester from the browser or the 
Toolbar, a WRSApp object is launched. At its creation 
the WRSApp object creates a DataManager object to guide 
the data and which initiates a CommunicationManager 
object to manage all communication between the client 
and the server. The CommunicationManager utilizes a 
RptManagerMsg object to create: 1) a GRTL; 2) a 
WRSCommWrapper for direct communication wxth the 
backend; and, 3) a WRSReportManagerUtilParser to format 
the data returned. In response, the Report Manager 
creates a Dispatcher object, which contains the 
business logic for handling metadata messages at the 
back-end and utilizes the services of a RMParser class. 
Upon determining that the client has sent a valid 
message, the appropriate member function is invoked t 
service the request. Upon receiving the message, the 
Report Manager creates the Parser object (RMParser) 
which takes the message apart and invokes a validation 
object which validates the message. 
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In response to the GRTL message, the data 
returned by the Report Manager server 250 for this 
particular request may include the following data in 
metadata format as follows: 

SRTL<ERROR=0, REPORTS = <RptCa tegoryDescriptionl 
=<RptTitlel. 1, RptTemplatelDl. 1. RptCategoryTypel . 1> , 
<RptTitlel.2, RptTemplatelDl. 2, RptCategoryTypel . 2» , 
<RptCategoryDescription2 =<RptTitle2 . 1 , RptTemplateID2 . 1 , 
RptCategoryType2.1>, <RptTi tle2 . 2 . RptTemplateID2 . 2 . 
RptCategoryType2 . 2» , 

<RptCategoryDescription#n=<RptTitle#n.n, 

RptTemplatelDttn.n, RptCategoryType#n . n> , <RptTitle#n . n, 
RptTemplatelDttn . n , RptCategoryType#n . n>» 



wherein RptlDtt indicates a standard report template ID, 
RptTitlett indicates the standard report template title, 
RptCategory# indicates the report category, e.g. 
Monitor Usage. Analysis Traffic, Historical, Executive 
Summary, Call Detail, etc.; and, RptDescript indicates 
the standard report template description displayed to 
the user. Thus, for each Report Template Category, 
there will be the list of reports with each entry 
containing a Report Template Title, a Report Template 
25 Description and the Report Template ID. 

The SRTL message is sent from the StarWRS RM 
proxy server to the report requestor for presentation 
to the customer. Specifically, the SRTL response is 
built inside the esql wrapper function after obtaining 
the necessary information through the stored procedure 
from the Report Manager Informix database. The Report 
Manager creates the RMServerSocket object and sends the 
SRTL message back to the client. 
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To retrieve details of the standard report 
template, the GRTD request message request is sent 
having content shown in the table in Appendix A. When 
specified, the Report ID field indicates an existing 
report that a user may wish to edit. 

The SRTD response generated by the RM server 
is formatted in metadata as follows: 
< Report Template ID=ID#, 

NODEl=<node levell, label valuel, assigned unique 
screen identif icationl , >, 

NODE2=<node level2, label value2 , assigned unique 
screen identif ication2 , <control ID2.1. field 
value2.1, data location2 . 1> , <control ID2 . 2 , field 
value2.2, data location2 . 2> , < >;> • 

NODE#n=<node levelttn, label value#n, assigned unique 
screen identif icationttn , <control ID#n.l. field 
valueta.l, data locations. 1> , <control ID#n.2. field 
value#n.2, data location#n . 2» 

in the SRTD message, the MetaTreeData Label 
fields include such values as General, Report Name, 
Report Description, Scheduled Execution, etc. The 
MetaCtrllnfo MetaField Value fields may be blank or may 
contain the selection options available to the user. 
This information is taken from the report template 
database. 

As another example, when a report request is 
submitted to retrieve a full list of user created 
reports from a user report table, i.e., a template list 
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for a particular report product, category, and type, 
the example metadata format is as follows: 

GURL<USERID=jeanvnet2,RPTTMPID=l,ENTPID=00022924,PRODUCT=T 
, DATACAT=U> 

with UserlD and ReportTemplatelD fields specified. 
Specifically, this process entails invoking the 
Communication Manager object to communicate with the RM 
server in order to obtain a SURL metadata message. The 
CommunicationManager utilizes the RptManagerMsg object 
to create: 1) a GURL, 2) a WRSCommWrapper for direct 
communication with the backend, and, 3) a 
WRSReportManagerUtilParser to format the data returned. 
The parser returns a hash table containing the User 
Report List. At the RM server, the Report Manager 
creates an Dispatcher object that contains the business 
logic for handling metadata messages at the back-end 
and utilizes the services of the RMParser class. Upon 
determining that the client has sent a- valid message, 
the appropriate member function is invoked to service 
the request. The Report Manager, upon receiving a 
message, creates a Parser object (RMParser) which takes 
the message apart and invokes a validation object which 
validates the message. 

In response to the GURL request, the data 
returned is taken from a user report table in the RM 
server database. The generic SURL message in Metadata 
format returned by the RM server 250 includes the 
following information: 
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REPORTS = <UserRptCategoryl - <UserRptTitlel . 
UserRptlDl, activeflag, report type, statusdate 
», <UserR P tCategory2 = <UserRptTi tle2 , 
UserRptID2, activeflag, report type, 
statusdate»,.~ <UserRptCategory#n 

<UserRptTitle#n, UserRptlDttn, activeflag, report 
type, statusdate>» 

wherein for each user report category, there is a list 
of reports where each entry contains a UserRptID* 
indicating a user-defined report template ID, a 
UserRptTitle* indicating the user's report template 
title and a UserRptCategory# indicating the user 
report category. Specifically, the SURL response is 
built inside an esql wrapper function after obtainrng 
the necessary information through a stored procedure 
from the Informix database. The Report Manager creates 
the RMServerSocket object and sends the SURL message 
back to the client. 

To retrieve the details of a specific user's 
report, the GURD message is sent having data as 
contained in the table shown in Appendix A. 
specifically, when the user selects a report from the 
inventory List on the Report Requestor, a Communication 
Manager object is invoiced to communicate with the RM 
server in order to obtain a SURD metadata message. 
CommunicationManager object first utilizes the 
RptManagerMsg object to create: 1) a GURD metadata 
message, 2) a WRSCommWrapper for direct communication 
with the backend, and 3) the RSReportManagerUtilParser 
to format the data returned. The parser organizes the 
data into a series of nodes which are utilized to 

-72- 



SUBSTITUTE SHEET (RULE 26) 



WO 99/16207 



PCT/US98/20148 



create the report builder tree on the report requestor 
customization screen. Later this data will be extracted 
from the node and used to construct the screen related 
to the node. The Report Manager server creates the 
MCIDispatcher object which contains the business logic 
for handling metadata messages at the back-end and 
utilizes the services of the RMParser class. Upon 
determining that the client has sent a valid message, 
the appropriate member function is invoked to service 
the request. The Report Manager, upon receiving a 
message, creates the Parser object (RMParser) which 
takes the message apart, invokes a validation object 
which validates the message and builds a response 
inside the esql wrapper function after obtaining the 
necessary information through the stored procedure from 
the Informix database. The Report Manager creates the 
RMServerSocket object and sends the SURD/SRTD message 
back to the client. The responsive SURD metadata 
message corresponding to a retrieve user report detail 
(GURD) request has the following metadata syntax: 

< Report Template ID=ID#, 

NODEl=<node levell, label valuel, assigned unique screen 
identif icationl , > , 

NODE2=<node level2 , label value2 , assigned unique screen 
identif ication2 , <control ID2.1, field value2 . 1 , data 
location2 . 1> , <control ID2 . 2 , field value2.2, data 
location2 . 2> , < , . 
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NODE#n=<node levelttn, label valued, assigned unique 
screen identification^ control iDtn.l. field value^l. 
data locations. l>. control IDttn.2. f ield value#n . 2 , data 
location^. 2> , <..,..,- 

This response thus may include the report information 
having detailed items including: UserReportID (UserT.D) . 
User's report name (UserName) . product (UserProd) , 
Threshold (UserThreshold) . User Report Description 
(UserDescript) . Report Columns (UserFields) . Report 
column headings (UserHeaders) . and, in addition, 
customization options with fields indicating, inter 
alia, columns to display (UserHeaders), user -defined 
criteria (UserCri teria) , a sort order (UserOrder) and 
scheduling selections (UserSched) , the last update of 
this report (UserLastUpdate) and, the Report status (if 
adhoc) (UserStatus) , etc. 

If a request is made to add a user-created report 
to a User_report table maintained by the RM Server 250 
and the RS server 260. the ARB metadata message having 
fields defined in the table provided in Appendix A is 
processed by the RM server 250. as indicated at step 
628 Figure 13(a) . An example message in metadata 
format to initiate the addition of a user-created 
report for ODS (Inbound/Outbound) reporting data is as 
follows : 

ARD<USERID=jeanvnet2,ENTPID=00022924,STDRPTID=90, 
NAME=City Summary 

Outbound, PRODUCT=S,CATEGORY= Analyze Traffic 
THRESHOLD=<RECCOUNT=20>,SCHEDULE=A<START=19980602 
0000,END=199807151200>,RANGETYPE=1,SCHEDTYPE=A,TI 
MEZONE=45 , BILLING=INBOUND«90000003 , 90000003><NA, 
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NA><NA.NA»INBOUND«9 0000004 , 90000004><NA, NA><NA, 
NA»,CARDNO=<654654*~54654654 6546 54 65>, IDAC=<4 654 

6 546*~1246> , GEO=GEO«00 1 , 001 

USA/WORLDZONE1XNA, NAXNA, NAXNA, NAXNA, NA»GEO« 

5 001,001 

USA/WORLDZONElxCO, CO><NA, NAXNA, NAXNA, NA» , OACC 

ESS = <4~1> , ODI STRANGE= <A~F> , OUSAGE=<5~4> , SORTBY=<5 
4D> , DESCRIPTION=This report summarizes call 
detail by the terminating city and state (USA) / 
10 province (CA) . The report is based on the 

date/time ranges and report criteria 
selected. , cOLUMNS=<54~55~67~62~36~61~58~63~64~66~ 
6 5> , ACTIVE=1 , TOTALMODE= 0 , EMAIL=0 , PAGE=0 , 
LANG=123 4, CURR=234 5> 

In this example, the "NAME" field refers to the 
Report Name (e.g., city summary); the "PRODUCT" 
field refers to the report product (Vision) ; the 
"THRESHOLD" field refers to the record count; the 
20 "DESCRIPTION" field refers to the report 

description; the "COLUMNS" refers to the number of 
columns specified for a report by the user; the 
"BILLING" field refers to the specified report 
billing entitlement, i.e., billing hierarchy; the 
25 "IACCESS" field refers to the inbound access type 

and the "OACCESS" refers to the outbound access; 
the "SORTBY" field indicates the report column 
sorting customization with "A" indicating column (s) 
having data to be sorted in ascending order and, 
30 "D" indicating column (s) having data to be sorted 

in descending order; the "SCHEDULE" field referring 
to the scheduling type, e.g., with "A" indicating 
an ad -hoc report, and the user specified date range 
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15 



on which to report as indicated by the "START" and 
"END " fields, and additionally, the scheduling 
frequency information in the case of a -currxng 
report; the SUBTOTALCOLUMNS field, referrxng to the 
report columns having, data to be subtotaled; and 
the "EMAIL" and "PAGE " fields indicating reporting 
notification via e-mail or paging, respectively. 

Furthermore, for each of the metadata 
.essages in Appendix A, including the -let^eport 
Definition (DRD) , copy report definxtxon (CRD), and 
update report scheduling (ORS) messages, the report 
Manager server 250 responds to the Report Requestor 
with the processing results. In the case of a copy 
report, a new User Report ID is assigned and 
returned by RM. When editing an exxstxng StarODS 
(priced call data) report, the user may make 
changes to the Report Title, the Report 
Description, the Report scheduling, the 800 numbers 
and thresholds, and may customize number of rows 
report columns, access codes, access types ; *xllxn, 
Jcation, geographic location, paging notxf icatxon, 
and e-mail notification. More specif really , when 
the user selects a report from the inventory list 
or a new report, an WRSEdit Screen is launched to 
, 5 provide the editing capabilities which are 

available for the report format. WRSedit guxdes 
the screens through the process of retrieving the 
screens' data. Some of the screens need data whxch 
has not yet been retrieved, such as 800 numbers or 
30 geographic locations. These screens manage the 

requests to the DataManager object to create the 
get pick list (GPL) message (Appendix A) , which 
launches the communicationManager object to perform 



20 
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this task. The CommunicationManager utilizes the 
RptManagerMsg object to create the GPL , the 
WRSCommWrapper for direct communication with the 
backend, and the WRSReportManagerUtilParser to 
5 format the data returned. In response, the Report 

Manager server creates the MCIDispatcher object and 
invokes the MCIRMParser class . Upon determining 
that the client has sent a valid message, the 
appropriate member function is invoked to service 
10 the request. The Report Manager, upon receiving a 

message, creates the Parser object (RMParser) which 
takes the message apart and a validation object is 
invoked which validates the message. The response 
is built inside the esql wrapper function after 
15 obtaining the necessary information through the 

stored procedure from the Informix database. The 
Report Manager creates the RMServerSocket object 
and sends the GPLA message back to the client. 

Having described the functionality of 
20 selecting and/or generating a report and 

customizing it, reference is now had to the process 
for running the report request in StarODS. 
Particularly, in the preferred embodiment, the user 
may select a save and exit report option, or a save 
25 and run report option. In either scenario, an 

WRSEdit object enables a WRSScnMgr object to save 
the report to the RM server. The WRSScnMgr object 
launches each screens save method which 
communicates with the DataManager object to place 
30 the screens data in its corresponding WRSNode . 

Once all of the WRSNode objects have been updated, 
the WRSScnMgr object calls the DataManager object's 
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SaveReport method to build a hash table to contain 
all of the report's data. The CommunicationManager 
utilizes the RptManagerMsg object to create the ARD 
metadata message from the hash table, the 
5 WRSCommWrapper for direct communication with the 

backend, and the WRSReportManagerUtilParser to 
handle any errors thrown by the server. The Report 
Manager creates the Dispatcher object, and utilizes 
the services of the RMParser class and validation 
10 objects. Upon determining that the client has sent 

a valid message, the appropriate member function is 
invoked to service the request. The response is 
built inside the esql wrapper function after 
obtaining the necessary information through the 
15 stored procedure from the RM database. The Report 

Manager creates the RMServerSocket object and sends 
the ARDA message back to the client. 

As illustrated in Figure 13 (a) , at step 
630, in reference to user selection of a Save and 
9 0 Run report option, the report is marked as 

scheduled and saved in a user_table in the Report 
Scheduler server 260 via the Report Manager. 
Subsequently, as indicated at step 630. the Report 
Scheduler server 260 generates an ARD message 
o 5 (Appendix D) and sends the ARD message to StarODS 

DSS server for which the DSS has a predefined 
interface, as described herein. 

Next, as indicated at step 632, the DSS 
receives the request and acknowledges receipt. 
30 specifically, when the request is received it is 

first validated with StarOE to ensure that the user 
is entitled to receive information about the 
selected product corp and number (s). Once the 
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request passes validation, the DSS IAIO reads the 
header to determine which Data Mart will ultimately 
be queried. It then parses the metadata into a 
format which the COTS software can readily convert 
5 into a SQL statement, as indicated at step 635, 

Figure 13(b), and adds the report to the DSS report 
queue based upon type (Daily, Weekly, Monthly, 
Adhoc) and associated DataMart, as indicated at 
step 638. It should be understood that at this 
10 point, the request has been flagged as submitted in 

the RM database, as indicated at step 633. 

From this point forward, DSS activity is 
controlled by a control process and progress or 
errors are logged internally in the DSS system. 
15 This control process includes logic enabling the 

prioritization of report requests and application 
of rules defining the order in which they should be 
executed. Thus, at the appropriate time, depending 
on the type or report, reporting period and other 
20 parameters, the Information Advantage query engine 

selects the report from the queue, as indicated at 
step 640, which action is logged in the report 
status table (Appendix I) as indicated at step 642. 
The SQL statement is then built by Decision Suite™ 
25 and routed to the appropriate data mart for 

execution in the manner as described herein, as 
indicated at step 643. The query engine generates 
the SQL statement from the metadata and executes 
the report which action is logged in the report 
30 status table as indicated at step 645. Next, as 

indicated at step 648, the query results are 
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returned, and. a post-SQL formatting process is 
invoked . 

More particularly, as shown in Figure 
12(b), a Formatter module 395 may perform various 
report result transformations including: 1) 
Converting of column headers generated by 
information Advantage* into appropriate column ids 
that are recognizable to the StarWRS client viewer 
functionality (as indicated at step 650, Figure 
13(b)); 2) Provide subtotaling for specific 
requested "subtotal by" columns in the format 
required by the StarWRS client interface (as 
indicated at step 653, (Figure 13(b)) and provides 
report-based totals as requested by customer; 3) 
converting binary stream data file to ASCII text 
file (as indicated at step 655. Figure 13(c)); 4) 
implementing Replace logic, e.g.. replacement of 
-TAB" delimiters with appropriate "Comma" field 
delimiters (as indicated at step 657 Figure 13(c)); 
5) implementing Repeat /Padding logic, i.e., 
identifying compressed columns /values and 
decompressing (or repeating) the values that were 
compressed; 6) providing alphanumeric translations 
for any encoded data elements returned in the 
result set data file (as indicated at step 659, 
Figure 13(c)); and. 7) adding new computed /derived 
columns, e.g., percent s, averages of column data 
values, etc., as requested by customers on specific 
reports . 

Particularly, as shown in Figure 12(b), 
the Formatter process 395 reads the *.hdr files and 
♦.data files from the Decision Suite™ result set to 
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obtain respective column names and report data. 
Particularly, the formatter process for converting 
Column Headers from Information Advantage® column 
header names to column ids implements a lookup of 
5 column ids in a column__id's table, shown in 

Appendix I, based on column header names. 

Then, the formatter process reads the request 
table 390 for total /subtotal , threshold, etc. 
information associated with the current report 
10 request and determines any other formatting 

features to be enabled for a particular result set. 
As shown in the example Request Table of Appendix 
I, parameters passed to the formatter module 
indicate any report request specific details that 
15 are required by the Formatter. For example, for 

report totals, a "total_mode" variable is used to 
indicate if report totals and/or sub- totals should 
be included. Particularly, Column IDs 
representing the data columns upon which 
20 subtotaling is based are passed as parameters to 

the Formatter process 395 and are referred to as 
"Break Columns" . At appropriate changes in values 
for these break columns, the formatter generates a 
subtotal line for subtotaling the applicable 
25 additive facts including, for example, Call Amount, 

Call Duration, and Call Count. 

Furthermore, the formatter reads a Column 
id table 396 (detailed in Appendix I) to determine 
data types and if any data translations are needed. 
30 As computed/derived columns may be 

included or excluded from customer report requests, 
• the Formatter process 395 for calculating new 
computed/derived columns on specific customer- 
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requested reports are provided on a report request 
basis. Example types of derived columns include: 
1) Percents, e.g., based on the additive data facts 
pertinent to the report request and are typically 
based on report totals and row amounts for Call 
Amount, Call duration, and Call Count; 2) Row-wise 
derived data elements as requested, which represent 
data elements computed based on original additive 
data elements on a row by row basis (i.e., column 
x/column y for each row in the result data file) 
and typically include average calculations such as 
Average # of Minutes per Call, Average Amount per 
Call and Average Amount per Minute. Appendix I 
illustrates a derived column "percent" calculation 
indicated in the Column ID table showing an 
equation for calculating a value of a particular 
value (C36) divided by a column total (CT36) x 100. 

The Formatter process 395 may 
additionally perform alphanumeric translations for 
any encoded data elements returned in the result 
set data file by implementing appropriate lookup in 
a Translation table 397, such as the example 
Translation Table provided in Appendix I, and 
replacing the code. 

Referring back- to Figure 13(c), after, 
formatting the report, as indicated at step 660, a 
message is sent to the control process to update 
the request status table 391. It should be 
understood that, if a failure occurs during 
formatting, the error log is updated and a status 
message sent to the request status table 391, as 
well. Then, as indicated at step 665 (Figure 
13(c)), the formatter 395 creates a *.csv (Comma 
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Separated Value) or . txt file, gives the file a 
unique name and saves the file. Preferably, a 
*.csv is the file generated if the report is 
successfully generated. As indicated at step 668, 
5 the *.csv report/data file is then "pushed", 

implementing FTP , to the StarODS server's directory 
on the Inbox server 270. The StarODS server 400 is 
responsible for generating unique file names within 
their directory on the Inbox server 270. For 
10 example, the following directory and file naming 

conventions used for reports generated by the 
StarODS server are labeled inbox\f iles\ods with 
text files having the suffix * . txt or * . txt_zip 
(compressed) , and comma separated files having a 
15 suffix *.csv or *.csv_zip (compressed) . 

Finally, as indicated at step 670, once 
the file has been successfully transferred to the 
Priced reporting directory on the Inbox server , and 
the request status table 391 appropriately updated 
20 at step 675, the NRL process (Figure 11(b)) 

generates and transmits an NRL message to the RM 
Server 250 notifying it of the report file name and 
location in the Inbox, requestor information, and 
if the transfer was successful. This is 
25 accomplished by using a "NRL" metadata message. 

Appendix B provides a table comprising 
the Notify Report Location parameters used for the 
NRL Metadata messaging sent by StarODS fulfilling 
server to the RM Server 250 when a requested report 
30 is complete. An example NRL message sent from the 

ODS server 400 to the RM server 250 is as follows: 

NRL<TYPE=S im - Msg - 40 , ENTPID=000229 24 , USERID=dorod, 
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STDRPTID=40 . USERRPTID=34 15 , REQUESTID=20341 , COMPRESS=0 
, L OC=/inbox/files/testOD S /STDRPTID43TM_082598_084920. 

CSV, FSIZE=389 , PRESORTED=0> 

5 An NRLA response is sent back to the DSS 

as shown in Appendix B. 

Once the RM server 250 has received the 
NRL message from the fulfilling server, it verifies 
the file's presence and builds a metadata file, 
10 e g . by compressing the appropriate metadata (for 

displaying the report) into a . MTD file. This . MTD 
file is utilized by the Report Viewer to know how 
to display the report. The Report Manager server 
creates a file including the metadata using the 
15 same file name as the report/data file, but having 

the following suffix: * .mtd or * .mtd_zip indxcatxng 
a metadata or compressed metadata file, 
respectively . 

Appendix F details the parameters that 
20 are passed in the GET METADATA messaging for 

indicating to the Report Viewer how to display a 
requested report. For example, a GET METADATA 
message corresponding to an Priced TVS fulfilling 
server report is as follows: 

<METADATA=<CRITERIA=<Name=UsageSummary292AADescriptio 

n= This report summarizes calls based on call type.AA 
Report_Level = <INBOUND«90000001,90000001><NA,NA><NA,N 



25 



30 



A>> 



I N BOUND«90000002.90000002><,><,»>AAOption S =A AS chedu 
ling_Information- A one_Time-ADates=<06/01/199800:00/ 
-07/01/199800 : 00 , >A AT imezone=EST, Lang=1234 , Curr-2345> 
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DEFAULT GRAPH MODE=0 A ADEFAULT__GRAPH TYPE = 0 A ADEFINE — X — AXIS 

AAX_AXIS_COLUMN= aaDEFAUL T_Y__COLUMNS = <> a A 
COLUMN_DISPLAY_ORDER=<105AA114AA6 7AA62AA3 6AA61AA5 8AA6 

3 A A64 A A6 6 a a6 5> a ASORT ALL0WED=1 A APRESORTED=0 A A 

PRESUBTOTALED=1AATOTALMODE=OAASORT_COLUMN S=<105A>aa 

SUBTOTAL COLUMNS = <> a AS ELECTED SECTION=0 A A 

MET AC O LUMN = < MET A_C O LUMN_I D = 1 0 5 a A 

COLUMN_LABEL=Usage 

Descr ip tion A ADATATYPE=S A ADECIMAL=0 A A 

HIDEABLE= 1 A AGRAPHABLE=0 a AWIDTH=20 A ACALCULATE=0 A A 

CALCULATE EXPRESS I ON= > A AMETACOLUMN=<META__COLUMN_ID= : l 1 

4 a A 

COLUMN_LABEL=Range/DistanceDescriptionAADATATYPE=SAAD 
EC IMAL= 0 a AHIDEABLE= 1 a AGRAPHABLE=0 a AWIDTH=2 0 a AC ALCULAT 
E=0 a A 

CALCULATE EXPRESS ION=> AAMETACOLUMN= :< META_COLUMN — ID=67 

AA 

COLUMN__LABEL=Calls A ADATATYPE=I A ADECIMAL=0 A AHIDEABLE= 1 
AA 

GRAPHABLE = 1AAWIDTH=7AACALCULATE=0AACALCULATE__EXPRESSI 
ON=> 

AAMETACOLUMN=<META_COLUMN_ID=62AACOLUMN__LABEL=% 
CallsAA 

DATATYPE=N A ADECIMAL=1 A AHIDEABLE=1 A AGRAPHABLE=1 AAWIDTH 
= 7aa 

CALCULATE=0 AACALCULATE EXPRESSION=> A A 

METACOLUMN=<META_COLUMN_ID=3 6AACOLUMN_LABEL=MinutesAA 
DATATY PE =N A ADEC IMAL= 1 A AHIDEABLE= 1 a AGRAPHABLE= 1 a AWIDTH 
= 8 A A 

CALCULATE=0 AACALCULATE EXPRES S ION=> A A 

M ET AC O L UMN = < MET A_C O LUMN__I D = 6 1 A AC O LUMN_L AB EL — % MinAA 
DATATYPE=N A ADECIMAL=1 A AHIDEABLE= 1 A AGRAPHABLE=1 A A 
WIDTH= 5 a ACALCULATE= 0 AACALCULATE EXPRESS I ON=> A A 
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METACOLUM N =<META_COLUMN_ID=58AACOLUM N _LABEL=AmountAAD 
ATATYPE=C A ADECIMAL=2 A AHIDEABLE=1 A A 

GRAPHABLE= 1 a AWIDTH= 7 a AC ALCULATE= 0 A AC ALCULATE EXPRES S I 
ON=> 

5 a AMET AC O LUMN = < MET A CO LUMN — I D = 6 3 A ACO LUMN LAB E L= % Amt A A 

DATAT YPE=N a ADEC IMAL= 1 A AHIDE ABLE= 1 A AGRAPHABLE= 1 A AWIDTH 
= 5AA 

CALCULATE=0AACALCULATE_EXPRESSION=>AA 

MET ACOLUMN= < META_COLUMN_ID=64 AACOLUMN LABEL=Avg 

10 Min/Call 

AADATATYPE=NAADECIMAL=2AAHIDEABLE=1AAGRAPHABLE=1 A A 

WIDTH=12 A ACALCULATE=0AACALCULATE_EXPRESSION=>AA 
METACOLUMN=<META_COLUMN_ID=6 6 A ACOLUMN_LABEL=Avg 

DATATYPE=N A ADECIMAL=2 AAHIDEABLE=1 A AGRAPHABLE=1 AAWIDTH 



15 



20 



25 



30 



= 12 

a A CALCULATED AACALCULATE_EXPRESSION=>AA 



MET AC O LUMN = < MET A_C OLUMN — I D = 6 5 AACOLUMN — LABEL=Avg 
Amt/Min A A 

DATATYPE=N A ADECIMAL=2AAHIDEABLE = 1 A AGRAPHABLE=1 A A 
WIDTH=11AACALCULATE=OAACALCULATE_EXPRESSION=»> 

* <METADATA= <CRITERIA= <Name=My Report, 
Total=Totals are located at the bottom of the 
report., Description=My report description, 
Number_Dialed=<800#l. 800#2, 800#n>, 
Scheduling_Information= Recurring, Dates- 
Monthly» DEFAULT_GRAPH_MODE=l, 
DEFAULT_GRAPH_TYPE=1 , DEFINE_X_AXIS=1 , 
X_AXIS_COLUMN=2 , DEFAULT_Y_COLUMNS=<5 , 6> , 
COLUMN_DISPLAY_ORDER=<l , 2 , 3 , 4 , 5 , 6> , 
COLUMN_STORED_ORDER=<4 , 3 , 2 , 5 , 6 , 1> , 
SORT_ALLOWED=l, PRESORTED = 1, TOTALMODE=3 , 
SUBTOTCOL=<5,6>, SELECTED SECTIONS, 
METACOLUMN=<META_COLUMN_ID=l . COLUMN_LABEL=name , 
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DATATYPE=S , DECIMAL=0 , HIDEABLE= 1 , GRAPHABLE=0 , 
WIDTH=10, CALCULATED, CALCULATE_EXPRESSION=<4 / 
7>>>> 



Once the metadata file corresponding to 
the requested report is build by the Report 
Manager, the RM ftp's the . MTD file to the Inbox 
server. The RM server additionally updates a 
User_report table status field with a status "C" 
indicating completion . 

Once the Report Manager has updated the 
status field, the RM server 250 then adds the 
report to the user's Inbox. 

Appendix C provides a table showing the 
fields for the metadata messaging between the RM 
server 2 50 and the Inbox server 270 for adding an 
item into the StarWRS system Inbox server 270, and 
the respective acknowledgment message format back 
from the Inbox server. In the "A" message found in 
Appendix C, the "LOC" field includes information 
about where the report data is located. For 
example, a metadata message indicating to the Inbox 
server that a priced ODS server report is available 
is shown as: 

A<CATEGORY=R , TYPE= traf f ic , REQUESTID-32197 , USER 
ID=LynneLevy2 , RPTID=15 0 , PRIORITY= , COMPRESS = 0 , U 
NOTIFY=0 , MMADDR= , MMTEXT= , PGT= , PGPIN= , PGTXT= , RP 
TCATEGORY= Service Location & Hour, 
LOC=/inbox/f iles/ods/9 02512294STDRPTID10.CSV,E 
NTPID=103 24 48 8, RQSTDT=1998 -01-02 
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15:18. FSIZE=3705,RPTTITLE=Summary by Service 
Location and Hour , MSIZE=3322> 

Particularly, the RM server supplies a 
metadata "A" message, to the Inbox indicating the 
FTP file location. Via the report viewer, the 
report is now available for viewing, downloading, 
saving, or printing by the user. Particularly, as 
shown in the exemplary nMCI home page in Figure 4. 
the nMCI Interact Message Center icon 77 may be 
selected which will cause the display of a web page 
including the message center dialog window. From 
the message center dialog windoe, a user may select 
from among three tabs, one of which, a reports tab, 
enables the retrieval of both a data file and a 
metadata file from the Inbox Server corresponding 
to those reports that have been run and available 
for customer viewing. Information provided for 
display by the message center display 325 xs 
provided by the User_table which keeps track of the 
status of all reports for a particular user. By 
double -clicking a chosen report, a report viewer 
application is enabled to display the chosen report 
on a web-page. To view the report the user selects 
the report and, the report metadata and the 
appropriate viewer are uploaded to the user 
(client) workstation. 

As mentioned herein with respect to 
Figure 3, the messages created by the client Java 
software are transmitted to the StarWeb (DMZ) 
Server 44 over HTTPS . For incoming 
(client- to- server) communications, the DMZ Web 
servers 44 decrypt a request, authenticate and 
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verify the session information. The logical 
message format from the client to the Web server is 
shown as follows: 

| | TCP/IP | | encryption | j http | I web header | I 
dispatcher header || proxy * specif ic data || 

where "M" separates a logical protocol level, and 
protocols nested from left to right. Figure 14 
illustrates a specific message sent from the client 
browser to the desired middle tier server for the 
particular application. As shown in Figure 14, the 
client message 340 includes an SSL encryption 
header 342 and a network - level protocol HTTP/POST 
header 344 which are decrypted by the DMZ StarWeb 
Server (s) 44 to access the underlying message; a 
DMZ Web header 346 which is used to generate a 
cookie 341 and transaction type identifier 343 for 
managing the cl ient /server session; a dispatcher 
header 34 5 which includes the target proxy 
identifier 350 associated with the particular type 
of transaction requested; proxy specific data 355 
including the application specific metadata 
utilized by the target proxy to form the particular 
messages for the particular middle tier server 
providing a service; and, the network- level 
HTTP/POST trailer 361 and encryption trailer 366 
which are also decrypted by the DMZ Web server 
layer 44. 

After establishing that the request has 
come from a valid user and mapping the request to 
its associated session, the request is then 
forwarded through the firewall 55b over a socket 
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connection 3 3 to one or more decode/dispatch 
servers 46 located within the corporate Intranet 
60. The messaging sent to the Dispatcher will 
include the user identifier and session 
information, the target proxy identifier, and the 
proxy specific data. The decode/dispatch server 46 
authenticates the user's access to the desired 
middle- tier service. 

As shown in Figure 14, the StarWeb server 
forwards the Dispatcher header and proxy- specif ic 
data to the Dispatcher, "enriched" with the 
identity of the user (and any other session- related 
information) as provided by the session data/cookre 
mapping, the target proxy identifier and the proxy- 
specific data. The dispatch server 46 receives the 
requests forwarded by the Web server (s) 44 and 
dispatches them to the appropriate application 
server proxies. Particularly, as explained 
generally' above with respect to Figure 7, the 
dispatch server 46 receives request messages 
forwarded by the DMZ Web servers and dispatches 
them to the appropriate server proxies. The 
message wrappers are examined, revealing the user 
and the target middle-tier service for the request. 

A first-level validation is performed, making sure 
that the user is entitled to communicate with the 
desired service. The user's entitlements in this 
regard are fetched by the dispatch server from 
Order Entry server 280 at logon time and cached. 
Assuming that the Requestor is authorized to 
communicate with the target service, the message is 
then forwarded to the desired service's proxy, 
which, in the accordance with the principles 
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described herein, comprises: 1) a report manager 
proxy 250' corresponding to the RM Server 250, 2) 
a report scheduler proxy 260 1 corresponding to the 
RS Server 26 0, and 3) an inbox server proxy 27 0* 
5 corresponding to the Inbox Server 270. Each of 

these proxy processes further performs: a 
validation process for examining incoming requests 
and confirming that they include validly formatted 
messages for the service with acceptable 
10 parameters; a translation process for translating a 

message into an underlying message or networking 
protocol; and, a management process for managing 
the communication of the specific customer request 
with the middle- tier server to actually get the 
15 request serviced. Data returned from the middle - 

tier server is translated back to client format, if 
necessary, and returned to the dispatch server as a 
response to -the request. 

Figures 15(a) and 15(b) are schematic 
20 illustrations showing the message format passed 

between the Dispatcher 46 and the application 
specific proxy (Figure 15(a)) and the message 
format passed between the application specific 
proxy back to the Dispatcher 46 (Figure 15(b)). 
25 As shown in Figure 15(a), all messages between the 

Dispatcher and the Proxies, in both directions, 
begin with a common header 110 to allow leverage of 
common code for processing the messages. A first 
portion of the header includes the protocol version 
30 115 which may comprise a byte of data for 

identifying version control for the protocol, i.e., 
the message format itself, and is intended to 
prevent undesired mismatches in versions of the 
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dispatcher and proxies. The next portion includes 
the message length 120 which, preferably, is a 32- 
bit integer providing the total length of the 
message including all headers. Next is the 
echo/ping flag portion 122 that is intended to 
support a connectivity test for the dispatcher- 
proxy connection. For example, when this flag is 
non-zero, the proxy immediately replies with an 
echo of the supplied header. There should be no 
attempt to connect to processes outside the proxy, 
e g the back-end application services. The next 
portion indicates the Session key 125 which is the 
unique session key or "cookie" provided by the Web 
browser and used to uniquely identify the session 
at the browser. As described above, since the 
communications middleware is capable of supporting 
four types of transport mechanisms, the next 
portion of the common protocol header indicates the 
message type/mechanism 130 which may be one of four 
values indicating one of the following four message 
mechanisms and types: 1) Synchronous transaction, 
e.g., a binary 0; 2) Asynchronous request, e.g., a 
binary 1; 3) Asynchronous poll/reply, e.g.. a 
binary 2; 4) bulk transfer, e.g., a binary 3. 

Additionally, the common protocol header 
section includes an indication of dispatcher - 
assigned serial number 135 that is unique across 
all dispatcher processes and needs to be 
coordinated across processes (like the Web cookie 
(see above)), and, further, is used to allow for 
fai lover and process migration and enable 
multiplexing control between the proxies and 
dispatcher, if desired. A field 140 indicates the 
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status is unused in the request header but is used 
in the response header to indicate the success or 
failure of the requested transaction. More 
complete error data will be included in the 
specific error message returned- The status field 
140 is included to maintain consistency between 
requests and replies. As shown in Figure 16(a), 
the proxy specific messages 375 are the metadata 
message requests from the report requestor client 
and can be transmitted via synchronous, 
asynchronous or bulk transfer mechanisms. 
Likewise, the proxy specific responses are metadata 
response messages 380 again, capable of being 
transmitted via a synch, asynch or bulk transfer 
transport mechanism . 

It should be understood that the 
application server proxies can either reside on the 
dispatch server 46 itself, or, preferably, can be 
resident on the middle -tier application server, 
i.e., the dispatcher front end code can locate 
proxies resident on other servers. 

As mentioned, the proxy validation 
process includes parsing incoming requests, 
analyzing them, and confirming that they include 
validly formatted messages for the service with 
acceptable parameters. If necessary, the message is 
translated into an underlying message or networking 
protocol. A list of Report Manager and Inbox proxy 
error messages can be found in Appendix E. If no 
errors are found, the proxy then manages the 
communication with the middle- tier server to 
actually get the request serviced. The application 
proxy supports application specific translation and 
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communication with the back-end application server 
for both the Web Server (java applet originated) 
messages and application server messages. 

particularly, in performing the 
verification, translation and communication 
functions, the Report Manager server, the Report 
Scheduler server and Inbox server proxies each 
employ front end proxy C++ objects and components. 
For instance, a utils.c program and a C++ 
components library, is provided for implementing 
general functions/objects. Various C++ parser 
objects are invoked which are part of an object 
class used as a repository for the RM metadata and 
parses the string it receives. The class has a 
build member function which reads the string which 
contains the data to store. After a message is 
received, the parser object is created in the 
KMDispatcher.c object which is file containing the 
business logic for handling metadata messages at 
the back-end. It uses the services of an RMParser 
class. Upon determining that the client has sent a 
valid message, the appropriate member function is 
invoked to service the request. Invocation occurs 
in MCIRMServerSocket.C when an incoming message is 
received and is determined not to be a talarian 
message. RMSErverSocket . c is a class implementing 
the message management feature in the Report 
Manager server. Public inheritance is from 
MCI Server Socket in order to create a specific 
instance of this object. This object is created in 
the main loop and is called when a message needs to 
be sent and received; a Socket. c class implementing 
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client type sockets under Unix using, e.g., TCP/IP 
or TCP/UDP. Socket. C is inherited by 
ClientSocket .C : : Socket ( theSocketType , thePortNum) 
and ServerSocket.C: : Socket ( theSocketType , 
thePortNum) when ClientSocket or ServerSocket is 
created. A ServerSocket . c class implements client 
type sockets under Unix using either TCP/IP or 
TCP/UDP. ServerSocket.C is inherited by 
RMServerSocket when RMServerSocket is created. An 
InboxParser.c class used as a repository for the RM 
Metadata. The class' "build" member function reads 
the string which contains the data to store and the 
class parses the string it receives. After a 
message has been received, the MCIInboxParser 
object is created in inboxutl.c which is a file 
containing the functions which process the Inbox 
requests, i.e, Delete, List, Fetch and Update 
(Appendix G) . Additional objects/classes include: 
Environ. c which provides access to a UNIX 
environment; Process. c which provides a mechanism 
to spawn slave processes in the UNIX environment; 
Daemon. c for enabling a process to become a daemon; 
Except ion. c for exception handling in C++ programs; 
and, RMlog.c for facilitating RM logging. In 
addition custom ESQL code for RM/database interface 
is provided which includes the ESQC C interface 
(Informix) stored procedures for performing the 
ARD, DRD , DUR, URS , GRD , CRD, and GPL messages. 
The functions call the stored procedures according 
to the message, and the response is build inside 
the functions depending on the returned values of 
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the stored procedures. A mainsql . c program 
provides the ESQL C interface for messages from the 
report manager and report viewer. 

A list of Report Manager and Inbox proxy 
5 error messages can be found in Appendix E. 

Outgoing (server - to- client ) 
communications follow the reverse route, i.e., the 
proxies will feed responses to the decode/dispatch 
server, which will encrypt the client-bound 
,0 messages and communicate them to the DMZ Web 

servers over the socket connection. The Web servers 
will forward the information to the client using 
SSL. The logical message format returned to the 
client from the middle tier service is shown as 
15 follows: 

| | TCP/IP I I encryption | | http | | web response | | 
dispatcher response || proxy- specif ic response || 



20 



25 



where || separates a logical protocol level, and 
protocols nested from left to right. The foregoing 
merely illustrates the principles of the present 
invention. Those skilled in the art will be able 
to devise various modifications, which although not 
explicitly described or shown herein, embody the 
principles of the invention and are thus within its 
spirit and scope. 
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APPENDIX A 



Retrieve Report Template List 





Parameter • - 

'•Name:fv -■• 


Parameter" '• 
'Type '•: - 




>* Acceptable^ i 

^yalue^-^V 


GRTL 


Request 


Char (4) 


Yes 




PRODUCT= 


Product ID 


Char (1) 


Yes 


V. C, S, T, H 


DATATYPE= 


Data Type 


Char (1) 


Yes 


R = Reports. 
D = Call Detail 
A = All data 
types 


DATACAT= 


Data Category 


Char(1) 


Yes 


P = Priced, 
U = Unpriced 


IO= 


Inbound/Outbo 
und 


Char (1) 


Yes 


I = Inbound, 
O - Outbound 
B = Both 



Sond Renort Temnlate List 





i ? Ba ra rriete iv 5 i'i-c £^1 








>V ■ \{i i\ ir Vr ' '\ ' ' } 


^Nafijes* 7 ' ' 


•.'.Typeci> 


r. j >: • ; ■ i^'j ' > : ^ • *v,^ ' 


-Valuer : > " 


SRTL 


Response 


Char (4) 


Yes 




ERROR= 


Error Code 


Char (4) 


Yes 


0 or error 


REPORTS= 


Data 


Char 


No 


See below 
formatting 





v Naine &v\ \/; vj 


;>Perameter>: i 






* Value ; . > ^ 


GRTD 


Request 


Char (4) 


Yes 




REPORTID= 


Standard Report 
ID 


Char (10) 


Yes 


Report ID (i.e., 
2. 44) 



Send Report Template Detail 



:fMes§age£sj 

C" " » 


*r? Namex;, r ;: 

; ? * ; ; j;.' ^ 


sMraViieter'pia 

^pepj'. 




Valuer 


SRTD 


Response 


Char (4) 


Yes 




ERROR= 


Error Code 


Char (4) 


Yes 


0 or error 


ID= 


Template ID 


Char (10) 


Yes 
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";l/fessag^ F i;' Parameten " J 
"Name-- >\ ,• 7. 


parameter" * ' 
Typer •> 


* ? ; - it 

■': r -./.v;. /• : \ »v 


•Acceptable| ^ 
Valuer ■ ^ 


GURL 


Request 


Char (4) 


yes 
Yes 


UserlD 


USERID= 
RPTTMPID 

ENTPID= 


User ID 4 
Report 
Template ID 
Enterprise ID 


Char (20) 
Char (10) 

Char (8) 


Yes 
Yes 


Template ID 
Enterprise ID 


PRODUCT= 
DATACAT 


Product ID 
Data Category 


Char (1 
Char (1) 


Yes 
Yes 


V.C.SXH 
p = Priced 
U = Unpriced 



Send User Report List 




Get User Report Detail 







Char (4) 


Yes 


GURD 
REPORTID- 


Request 
User Report ID 


Char (10) 


Yes 



Report ID (i.e., 245). 
Limit on unique user 
report Ids is 
2147483647 
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AparairfeterF : {: ; ~i 






SURD 


Response 


Char (4) 


Yes 




ERROR= 


Error Code 


Char (4) 


Yes 


0 or error 


ID- 


Template ID 


Char(10) 


Yes 




NODE= 


Data 


Char 




see above 
formatting 



||^es||ge^|||l 




Raramr ->h 

Type / - -! l 




i- " <:■>> ~-.| 


ARD 


Request 


Char (3) 


Yes 




USERID= 


User's ID 


Char (20) 


Yes 


UserlD 


ENTPID= 


Enterprise ID 


Char (8) 


Yes 


Enterprise ID- 
require 8 
characters 


STDRPTID= 


Standard Report 
ID 


Char (10) 


Yes 


Standard Report 
ID (i.e., 2, 44). 


NAME= 


User's report 
name 


Char(100) 


Yes 


User's designated 
name for this 
report (e.g., My 
Lonqest Calls) 


PRODUCT= 


Product 


Char(1) 


Yes 


Vnet = V, CVNS = 
C, Vision = S, Toll 
Free = T, 
Broadband = H 


CATEGORY= 


Report category 
Description 


Char 


Yes 


Examples are: 
Analyze Traffic, 
Standard Report, 
Telecommunicatio 
ns 


THRESHOLD 


Record limits 


Delimiter 


No 


holds 

RECCOUNT, 
RANKING, 
DURATION, ANI 
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RECCOUNT= Record count 



"RANKING- I TVS Ranking 



DURATlON= I TVS Duration 



Char (4) Yes 



Char (3) No 



Char (4) I No 



ANl= 



TVS AN I 



Char (3) No 



" SCHEDULE- Report schedule Char () No 



START- 



Start report 
schedule 



Char (12) 



No 



Maximum amount 
of records to be 
returned in the 
report results. If no 
threshold is 
received, the 
threshold for the 
standard report will 
be used. 



# of call ranks to 
show. If ranking is 
not passed, the 
default value will 
be used. 

# for call duration 
threshold. If 
duration is not 
passed, the default 
value will be used. 

# of Items in Most 
Frequent report. If 
AN I is not passed, 
the default value 
will be used. 



If scheduling 
information is not 
received, the 
Report Manager 
will only store the 
report. It will not 
send a request to 
the fulfilling server. 
No overlapping 
dates will be sent 
in the start/end 
pairs. 

A = Adhoc, H = 
Hourly, D = Daily, 
W= Weekly, M = 
Monthly, 



YYYYMMDDhhm 
m 

This parameter is 
only used if the 
report is Adhoc. 
There can be 
multiple start and 
find dates. 
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END= 


End report 

crhoHi do 


Char (12) 




YYYYMMDDhhm 
m 

This parameter is 
only used if the 
report is Adhoc. 
There can be 
multiple start and 
end dates. 


RANGETYPE 


Range type picked 
by the user 


Char(1) 


Yes if 
Adhoc 


1 = range 
0 = discreet 


SCHEDTYPE 


Schedule Type 
picked by the user 


Char(1) 


Yes 


A = Adhoc only 
R = Recurrinq only 


TIMEZONE= 


User's time zone 


Char (3) 


Yes 


User's time zone 
value as received 
from StarOE 


NDIALED= 


Filter 


Char 


Yes for 
TVS, No for 
all others 


Niimbpr ranae 
delimited by - 


BILLING= 


Hierarchy 


Char 


Yes for 
ODS, and 
TVS 

outbound. 

Ma fnr all 

IMU IUi all 

others 


Single or multiple 
\zalup<? from billino 
hierarchy. Must at 
least include the 
Corp ID 


CARDNO 


Card number 


Char 


No 


Single or multiple 
values 


IDAC= 


ID/Account Codes 


Char 


Mr, 

!MO 


Single or multiple 
values 


GEO= 


oeograpnicai 




NO 


Single or multiple 
values from 
geographical 
hierarchy. 


IACCESS= 


Inbound Access 


Char 


No 


Single or multiple 
values of inbound 
access 

codes(Example: 7) 


OACCESS= 


Outbound Access 


Char 


No 


Single or multiple 
values of outbound 
access codes 
(Example: 4) 


IDISTRANGE 


Inbound Distance 
Range 


Char 


No 


Single or multiple 
values of inbound 
distance ranges 
codes(Example: 2) 


IUSAGE= 


Inbound Usage 


Char 


No 


Single or multiple 
values of inbound 
usaae (Examle: 5) 
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PGTxt= 



Message 



Char(240) 



EMAIL= 



PAGE= 



indicates if user 
picked email. 



Char(1) 



Indicates if User 
picked page 



Char(1) 



Yes 
Yes 



0 = no, 1 = yes 



0 = no, 1 = yes 



LANG= 



Indicates the 
language a user 
picked. 



Char(4) 



No 



Default will be 
American English, 
the values are not 
defined. 



CURR= 



indicates the 
language a user 
picked 



Char(4) 



No 



Default will be 
American Dollar, 
the values are not 
defined. 



Add Report Definition Acknowledgment 




ARDA 


Response 


Char (4) 


Yes 




ERROR= 


Error Code 


Char (4) 


Yes 


0 or error 


USERRPTID 


User ReportID 


Char (10) 


No 


User Report ID 
(i.e.. 245). Limit 
on unique user 
report Ids is 
2147483647. 















^Narnesr '-• - ■' 








DRD 


Request 


Char (3) 


Yes 




USERID= 


User's ID 


Char (20) 


Yes 


UserlD 


USERRPTID 


User Report ID 


Char (10) 


Yes 


User Report ID (i.e., 
245). Limit on unique 
user report Ids is 
2147483647 



DRDA I Response I Char (4) | Yes 
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ERROR= 
USERRPTID 


Error Code 
User Report ID 


Char (4) 
Char (10) 


Yes 
No 


0 or error 

User Report ID (i.e., 
245). Limit on unique 










user report Ids is 










2147483647 



; - , . • v .:.Name-j "; ; /^ - ' 




fReqijirepf 


Valuer : r £ 


CRD 

USERRPTID = 


Request 
User Report ID 


Char (3) 
Char (10) 


res 
No 


User Report ID 
(i.e., 245). 
Limit on unique 
user report Ids 
is 2147483647 


NAME- 


User report 
name 


Char (50) 


Yes 


User report 
name 



Conv Report Definition Acknowledgment 



£M§ssaqs§ 



CRDA 


Response 


Char (4) 


Yes 




ERROR= 
USERRPTID = 


Error Code 
User Report ID 


Char (4) 
Char (10) 


Yes 
No 


0 or error 
User Report ID 
(i.e., 245). 
Limit on unique 
user report Ids 
is 2147483647 



Update Report : 
URS ^ 


>Pararnetei??;.-^ : i 

^Namei-V;^-^- 




-Required* 




USERRPTID 


User Report ID 


Char (10) 


No 


User Report ID 
(i.e., 245). Limit on 
unique user report 
ihq ?1 47483647 
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ACTIVE 


User Active 


Char(1) 


Yes 


0 - for saved/not 








scheduled 










1 - for scheduled 



Update Report Scheduling Acknowledgment 



URSA 


Response 


Char (4) 


Yes 




ERROR= 


Error Code 


Char (4) 


Yes 


0 or error 


USERRPTID = 


User Report ID j 


Char (10) 


No 


User Report ID 
(i.e., 245). 
Limit on unique 
user report Ids 
is 2147483647 



Get Pick List — Access 




GPL 


Request 


Char (3) 


Yes 




PL_ACCESS= 


Pick List Type 


Character 


Yes 


PL ACCESS 


IO= 


Inbound/Outboun 
d 


Char (1) 


Yes 


l=lnbound, 
O=0utbound, 


PRODUCT= 


Product 


Char(1) 


Yes 


T=Toll Free, V 
= Vnet. S = 
Vision, C = 
CVNS, H = 
Broadband 


DATACAT= 


Data Category 


Char(1) 


Yes 


U = Unpriced, 
P = Priced, 
B = Both 



Get Pick List Acknowledgement — Access 



;:-r .;, 1 Namer , , Va\u& 



GPLA 


Response 


Char (4) 


Yes 




ERROR= 


Error Code 


Char (4) 


Yes 


0 or error 


PL_ACCESS= 


Pick List Type 


Character 


Yes 


Access code, 
Description 
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Get Pick List - Fields 



~i* •." v-v^-v i r*v ^ : * 'to..-*-* r 

, : . - ... ■ i: 




,\ : - : ^ ! '~V" 'i 


Required^ 


r Acceptable^ 

:--\ •.•^.uss. 1 . to'.*.v' 

■v>> <r - K» c- ' -» • KM 


GPL 


Response 


Char (3) 


Yes 




PL FIELDS 


Pick List Type 


Character 


Yes 


PL_FIELDS 


RPTTMPID= 


Report Template 
ID 


Char (10) 


Yes 




l^pt Pirk I Jst Ackno 


wledf* ement - Fields 








- v.;;, • ': 




GPLA 


Response 


Char (4) 


Yes 




ERROR= 


Error Code 


Char (4) 


Yes 


0 or error 


PL_F1ELDS= 


Pick List Type 


Character 


Yes 


FieldID, 
FieldHeader, 
FieldColumnHi 
de, FieldSort 


r:e» Pick List — Dur 


ation 






r Parameter^ pe^ 


: iHequired ^ 


-Valuer - ' " ■ 


GPL 


Response 


Char (3) 


Yes 


single or 
Multiple Values 


PL_DURATION 


Pick List Type 


Character 


Yes 


PL_DURATIO 
N 


Get Pick List Ackn 


owledoement — Duration 






Ipi^ilPiiil 

EH : < f -- » - ,f % 






||cRequiredi 


\WaluB^\,<^,i/t 


GPLA 


Response 


Char (4) 


Yes 


Stnqte or 


ERROR= 


Error Code 


Char (4) 


Yes 


0 or error 


PL_DURATION= 
example 


Pick List Type 


Character 


Yes 


Duration 
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GPL 


Response 


Char (3) 


Yes 




PL TIMEZONE 


Pick List Type 


Character 


Yes 


PL TIMEZONE 


r!At Pirfc f .i«t Acknti 


wledeement — Time Zone 






*'•'''", 


r Namei > 7 ■ \ • \ 






riyaiue^ ; / 1 


GPLA 


Response 


Char (4) 


Yes 




ERROR= 


Error Code 


Char (4) 


Yes 


0 or error 


PL_TIMEZONE= 


Pick List Type 


Character 


Yes 


TimeZoneCode 
, Description 


Cct Pick List - Billi 




'V, v<»;« ^^«^/^s•; , • •♦•♦.•» 1 


^parameter;'. 


t»V. ' \ '-• A } : ■ •* K rVv £ " "■' 
.*£;- - a-. v., . 

j. • ♦ ^ ! . : r:V^;V.:^^v..^'j>A 


' \ -■ ;> " > , r * , ' 




GPL 


Response 


Char (3) 


Yes 




PL HIER 


Pick List Type 


Character 


Yes 


PL_HIER 


USERRPTID= 


User Report ID 


Char (10) 


Yes 


User report ID 





lill n h hi ^—^M 


RBequiire4ll 




GPLA 


Response 


Char (4) 


Yes 




ERROR= 


Error Code 


Char (4) 


Yes 


0 or error 


PL HIER- 


Pick List Type 


Character 


Yes 


hierarchy data 




nrqnhirol Hiprsrrhv • 


, • •'** *. • '-Namp- ' ; : . 




GPL 


Response 


Char (3) 


Yes 




PL GEO 


Pick List Type 


Character 


Yes 


PL GEO 


USERRPTID= 


User Report ID 


Char (10) 


Yes 


User report ID 
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^Mes^sge-i; i< , ' "or parameters . » 

',.*•' ■ ^Nania. ■ ' • ■ j 


?RpmmeteKi:ype«V 


.-. ' 


^Acceptgblex; 


GPLA 


Response 


Char (4) 


Yes 




ERROR= 


Error Code 


Char (4) 1 


Yes 
Yes 


0 or error 
qeo data 


PL GEO 


Pick List Type 


Character 











^ParanriBterATyp^ff 


jpequiredtf 




GPL 


Response 


Char (3) 


yes 




ERROR= 


Error Code 


Char (4) 


Yes 


0 or error 


PL RANGE 


Pick List Type 


Character 


Yes 


PL RANGE 


IO 


Inbound/ 
Outbound 


Char (1) 


Yes 


l=inbound, 
O=0utbound, 


PRODUCT= 


Product 


Char (1) 


Yes 


T=Toll Free, V = 
Vnet, S = Vision, C 
= CVNS, H = 
Broadband 


DATACAT= 


Data Category 


Char (1) 


Yes 


U = Unpriced, 
P = Priced, 
B = Both 



Get Pick List Acknowledgment - Static Range 



GPLA 


Response 


Char (4) 


Yes 




ERROR= 


Error Code 


Char (4) 


Yes 


0 or error 


PL_RANGE= 


Pick List Type 


Character 


Yes 


range code, 
description 


r* A » Dinl* 1 Serf 










, , _ ] ( Name^^ - i i * ► 


^Required!* 


frValue::-^ 


GPL 


Response 


Char (3) 


Yes 




ERROR- 


Error Code 


Char (4) 


Yes 


0 or error t 


PL USAGE 


Pick List Type 


Character 


Yes 


PL USAGE 


IO= 


Inbound/ 
Outbound 


Char (1) 


Yes 


l=lnbound, 
0=Outbound, 
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PRODUCT^ 


Product 


Char (1) 


Yes 


T=Toll Free, V 
= Vnet, S = 
Vision, C = 
CVNS, H = 
Broadband 


DATACAT= 


Data Category 


Char(1) 


Yes 


U = Unpriced, 
P = Priced, 
B = Both 



Get Pick List Acknowledgment - Static Usage 



- ]• parameter 



meter*, - * ! WiimSKi^eSiSlf^^ 

y • % . '* * l( 4 ^TV- Value *• " x ' 

' \ . 'V, 1 ' - ' )! ^ , --'j : y v j , - ' * * — j " *> f > 1 - ^ "V 



GPLA 


Response 


Char (4) 


Yes 




ERROR= 


Error Code 


Char (4) 


Yes 


0 or error 


PL_USAGE= 


Pick List Type 


Character 


Yes 


usage code, 
description 




: -Me»age& ;r r-T: Parameters- • 


gparameter^peif 


^Required* 


^Acceptable ; 
'Valuei 


GPL 

ERROR= 
PL LANG= 


Response 
Error Code 
Pick List Type 


Char (4) 
Char (4) 
Character 


Yes 
Yes 
Yes 


0 or error 
Lanquaqe code 



Get Pick List Acknowledgment -Language 



;AcceptableK~ : ^ 



• r _ i. - "7/ j - 










GPLA 


Response 


Char (4) 


Yes 




ERP>OR= 


Error Code 


Char (4) 


Yes 


0 or error 


PL_LANG= 


Pick List Type 


Character 


Yes 


Row 

information to 
follow 


i^n* PioL- I Set ^nrr 




^Me^sage^; 




' parameter-Type" 




^cceptabie^; ' 
; Valuer "f \ 




1 Resoonse 


1 Oharf4* 


I Yes 


j — i 
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ERROR= 



PL_CURR= 



Error Code 



Pick List Type 



Char (4) 



Yes 



0 or error 



Character 



Yes 



Currency code 









Valuer - V ^X J 


GPLA 


Response 


Char (4) 


Yes 




ERROR= 
PL CURR= 


Error Code 
Pick List Type 


Char (4) 
Character 


Yes 

Yes 1 


0 or error 
Row 

information to 
follow 
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APPENDIX B 





; -param!H-t •'•:**;]: 




jAcceptablesValue^l 

:•; ,*:<^'*;| 


NRL 


Request 


Char (3) 


Yes 




TYPE= 


Designates 
report type, call 
detail type, or 
news type 


Char (30) 


Yes 


e.g. Broadband, 
priced, real-time, 
exception, invoice, 
MIR, CCID, priced 
call detail, outage 


ENTPID= 


Enterprise ID 


Char (8) 


Yes 


Enterprise ID 


USERID= 


User's ID 


Char (20) 


Yes 


UserlD 


STDRPT1D= 


Standard Report 
ID 


Char (10) 


Yes 


Standard Report ID 
(i.e., 2, 44). 


USERRPTID 


User Report ID 


Char (10) 


Yes when 
fulfilling 
server is 
using the 
StarWRS 
Report 
Requeste 
r 


User Report ID (i.e., 
245). Limit on 
unique user report 
Ids is 2147483647 


REQUESTID 


Unique Request 
ID 


Char (10) 


Yes when 
fulfilling 
server is 
using the 
StarWRS 
Report 
Requeste 
r 


Unique request ID 
sent to fulfilling 
server in ARD. Limit 
on request ID is 
2147483647. 


PRIORITY= 


Standardized 
Network 
Management 
Priority Levels 


Char (1) 


ONLY 
news 


1 = fatal, 2 = major, 3 
= minor, 4 = 
info(default), 5 = no 
alert 


COMPRESS 


Designates 
whether the data 
. has been 
compressed 


Char(1) 


Yes 


0 = data not 
compressed, 1 = 
data compressed 


LOO 


Location 


Char (255) 


Yes 


File Path, name and 
extension 


FSIZE= 


Size of 

associated file in 
bvtes 


Char (10) 


Yes 


Limit is 2147483647 
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AcceptableiValuerv ■ 

. m WMM 


REPORTTIT 
LE= 


Report Title 


Char (100) 


Yes when 
fulfilling 
server is 
not using 
the 

StarWRS 
Report 
Requeste 
r 


Report tine xo De 
displayed in Inbox. 

V 


PRESORTE 
D= 


Indicates 
whether or not 
the fulfilling 
server sorted the 
data on their 
side. 


Char(1) 


Yes 


0 = not presorted, 1 
= is presorted. 


ERR= 


Used to when 
there is no report 
file, but there is 
an informational 
file. 


Char(1) 


No 


ERR=1 or 
ERR=0 


TOTAL= 


Fulfilling server 
totals 


Char 


No 


Sent by fulfilling 
server to indicate 
report totals. 
Column ID and total 
are passed. 


CATEGORY 


Report, call 
detail, or news 


Char(1) 


Yes for 

StarOE. 

Report 

Manager 

will 

determine 
for 

fulfilling 
servers. 


R = Report, D = Call 
Detail F = News 



Notify Report L< 










NRLA 


Response 


Char (4) 


Yes 




ERROR= 


Error Code 


Char (4) 


Yes 


0 or error 


USERID= 


User ID 


Char (20) 


Yes 


User ID 


USERRPTID 


User Report ID 


Char (10) 


Yes 


User Report ID (i.e., 
245). Limit on unique 
user report Ids is 
2147483647 
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ParameteKNae^Us 




Requirecl^VAcceptableiyalue. 


REQUESTID 


Unique Request 
ID 


Char (10) 


Yes when 
fulfilling 
server is 
using the 
StarWRS 
Report 
Requeste 
r 


Unique request iu 
sent to fulfilling 
server in ARD. Limit 
on request ID is 
2147483647. 




APPENDIX C 






•Param^^ • 




^Acceptab)eiValue^ ^ 


A 


Add request 


Char(1) 


Yes 


A = add 


SEV= 


Servity of 

notification 

message 


Char (1) 


No 


1,2, or 3 


CATEGORY 


Item category is 
an report, call 
detail, or news 


Char (1) 


Yes 


R = Report, D = Call 
Detail, F = News 


TYPE= 


Designates 
report type, call 
detail type, or 
news type 


Char (30) 


Yes 


e.g. Broadband, 
priced, unpriced, 
exception, invoice, 
MIR, CCID, priced 
call detail, outage 


USERID= 


Designates 
intended 
recipient or 
audience 


Char (20) 


Yes 


Starbucks username 
as assigned in 
StarOE 


RPTID= 


User report ID 


Char (30) 


Reports 
and data 
only 


User report ID (i.e., 
245) 


PRIORITY= 


Standardized 
Network 
Management 
Priority Levels 


Char (1) 


ONLY 
news 


1 = fatal, 2 = major, 3 
= minor, 4 = info 
(default), 5 = no alert 


COMPRESS 


Designates 
whether the data 
has been 
compressed 


Char(1) 


Yes 


0 = data not 
compressed, 

1 « data compressed 
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Typ^ i 


Mil ,..,.•*•;!• 


Acceptabl^alue^ 


UNOTIFY= 


Says if user 

bllUUiu uc pay 

or emailed when 
the Inbox item is 
received by the 
Inbox server 


Char(1) 


NO 


= Page, 2 = Email, 3 
= Email and page 


MMADDR 


Override email 


Char(75) 


No 


Must contain© e.g. 
userA@mci.com 


MMTEXT 


Override email 


Char(500) 


No 




PGT 


Override pager 

i yp e 


Char(1) f 


No 


As supported by 
Star OE 


PGPIN 


Override pager 
PIN 


Char(8) 


No 


Numerics only 


1 PGTXT 


LJverriQc paytii 
text 


Char(240) 
or | 

Char(20) ) 


No 


Alphanumeric pagers 
or 

Numeric paqers 


RPTCATEG 
j ORY= 


Report category 
(report name) 


Char (50) 


ONLY 
report 


e.g. — Longest Calls 


LOC= 


Location 


Char (255) 


Yes 


File Path, name and 
extension 


ENTPID= 


Enterprise ID 


<^nar ^o; 


Yes 


As assigned in 
StarOE 


RQSTDT= 


Report or data 
request 

date/time stamp 


Char (12) 


ONLY 
report or 
I data 


YYYY-MM-DD 
HH:MM 


FSI2E= 


Size of 

associated file in 
bytes 


Char (10) 


Yes 


Limit is 2147483647 


RPTTITLE= 


User-defined 
report title, call 
detail request 
name, or news 
short text 


Char (255) 


Yes 


Example: 

"Call Duration 
Summary" 


MSIZE= 


Size of 
associated 
metadata for 
transfer 


Char (10) 


ONLY 
report or 
data 


Limit is 2147483647 


ERRFLAG= 


Fulfilling server 
reported an error 


Char (1) 


No 


0 = no error (default), 

1 = error 
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Ariel Acknowledgment 













z 


Response 


Chard) 


Yes 


Z 


REQ= 


Request which is 
being 

acknowledged 


Char (1) 


Yes 


A, D, L, F. U 


ERROR= 


Error Code 


Char 


Yes 


0 = no error or error 
code 


INBOXID= 


Inbox ID 


Char(1 0) 


No 


Uniquely assigned id 



APPENDIX O 



Add Renort Definition 







— 1 


ARD 


Request 


Char (3) 


Yes 




ENTPID= 


Enterprise ID 


Char (8) 


Yes 


Enterprise ID 


USERID= 


User's ID 


Char (20) 


Yes 


UserlD 


STDRPTID= 


Standard Report 
ID 


Char (10) 


Yes 


Standard Report 
ID (i.e., 2, 44). 


USERRPTID 


User's Report ID 


Char (10) 


Yes 


User Report ID 
(i.e., 345). Limit 
on unique user 
report IDs is 
2147483647. 


REQUESTID 


Unique Request 
ID 


Char (10) 


Yes 


Unique Request 
ID. Limit is 
2147483647 


PRODUCT^ 


Product 


Char (1) 


Yes 


Vnet * V, CVNS = 
C, Vision = S, Toll 
Free = T, 
Broadband = H 


THRESHOL 
D= 


Record limits 


Delimiter 


Yes 


RECCOUNT, 
RANKING, 
DURATION, ANI 
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°^fcV^"' v > v: ' if 






RECCOUNT | 


Record count 


Char (10) 


No 


Maximum amount 
of records to be 
returned in the 
report results. If no 
threshold is 
received, the 
default reccount 
threshold from the 
report template will 
be passed. 


RANKING^ \ 


TVS Ranking 


Char (3) 


No S 


# of call ranks to 
show. If ranking is 
not passed, the 
default value will 
be passed. This is 
a TVS only 
parameter. Range 
is 1-400. 


DURATION= 


TVS Duration 


Char (4) 


No 


# for call duration 
threshold. !f 
duration is not 
passed, the 
default value will 
be passed. This is 
a TVS only 
parameter. 
Format is mmss. 
Ranqeis 1-5959. 


ANI= 


TVS ANI 


Char (3) 


No 


# of Items in Most 
Frequent report. If 
ANI is not passed, 
the default value 
I hp n«;pd This 

| Will L*w UOCU. • 1 »'w 

is a TVS only 
parameter. Range 
is 1-400. 


COLUMNS= 


Columns 


Char 


Yes 


These are the 
columns the user 
wants in their 
report. Field Ids 
are to be passed 
here (i.e., 5,17, 
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F1LTERS= 


Filters or Criteria 


Delimiter 


Yes for 


Contains multiple 
filters (i.e., 
NDIALED). If 
filters are not 
received, filters 
from the standard 
report template (if 
any) will be stored 
and/or sent with 
request to fulfilling 
server. 


NDIALED= 


Filter 


Char 


Yes for 
TVS, no for 
all others 


Number range 


BILLING= 


Hierarchy 


Char 


Yes for 
ODS, Yes 
for TVS 
Vision and 
VNET 
Outbound 


Single or multiple 
values from billing 
hierarchy. Must at 
least include the 
Corp ID 


DURRANGE 


Duration Range 


Char 


No 1 


Single or multiple 
values. 


OARDNO= 


Card Number 


Char 


No 


bmgie or multiple 
values from the 
duration pick list 


IDISTRANGE 
— 


Inbound Range 


Char 


No 


Single or multiple 
values from the 
Ranqe pick list 


ODISTRANG 
E= 


Outbound Range 


Char 


No 


Single or multiple 
values from the 
Ranae pick list 


IUSAGE= 


Inbound Usage 


Char 


No 


Single or multiple 
values from the 
Usage pick list 


OUSAGE= 


Outbound Usage 


Char 


No 


Single or multiple 
values from the 
Usage pick list 


IDAC= 


ID/Account Codes 


Char 




Single or multiple 
values 


GEO 


Geographical 


Char 


No 


Single or multiple 
values from 
geographical 
hierarchy. 


IACCESS= 


Inbound Access 


Char 


No 


Single or multiple 
values of inbound 
access items 
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Single or multiple 
values of 
outbound access 
items 



If sort order is not 
received, sort 
order for standard 
report will be used. 
If sort order is 
passed, it must be 
a column ID and 
ascending (A) or 
descending (D) 
(i.e., 1DL 



LABEL and 
OFFSET. 



Timezone label 
(ie, MST). 



User's Time Zone 
in relation to GMT 
e.g. +2, -5. Valid 
range is -1 2 
through +13. 
Offsets will be in 1 
hour increments 
for the 98.1 
release. 



The Report 
Scheduler will not 
send a request to 
the fulfilling server 
if the report was 
not scheduled. 
A = Adhoc, H = 
Hourly, D = Daily, 
W= Weekly, M = 
Monthly 



YYYYMMDDhhm 
m 

This parameter is 
only used if the 
report is Adhoc. 
These can be 
multiple start and 
end dates. Start 
and end times 
must be passed in 
pairs and will be in 
GMT format. 
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END= 



End report 
schedule 



Char (12) 



Yes 



YYYYMMDDhhm 
m 

This parameter is 
only used if the 
report is Adhoc. 
There can be 
multiple start and 
end dates. Start 
and end times 
must be passed in 
pairs and will be in 
GMT format. 



TOTALMOD 



Total mode the 
user selected. 



SUBTOTCO 
L= 



Subtotal columns 



Char (t) 



Char 



Yes for 
ODS, No for 
all other 
fulfilling 
servers. 
Yes if 



0 = None (default), 

1 = Subtotal, 2 = 
Total, 3 = Both. 



TOTALMO 
DE is 1 or 

3. 



Subtotal column 
IDs. 




USERRPTID User Report ID 



REQUESTID 



Char (10) 



Unique Request 
ID 



Char (10) 



Yes 



User Report ID 
(i.e., 245). Limit on 
unique user report 
Ids is 2147483647. 
Please use this 
token whenever 
possible. The only 
time it should not 
be used is when 
the fulfilling server 
cannot parse the 
message at all. 
Request ID. Limit 
is 2147483647. 
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APPENDIX E 



Report Manager Proxy Codes 



Error Code ' 
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Inbox Proxy Codes 



;Error;Code: 



ISB IBS S B ■ I" jinn" SSg »nv data requested 
fg S been jdjd S S inbU and wTtn^j dd^ 
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APPENDIX F 



Get Metadata 
METADATA= I 






Y " 
Hmm !■ 


/a|uet> \ V / > 




CRITERIA 25 
Name= 

TotalJnbound_A 
mounts 


Delimiter 
Mame of report 
Total inbound j 

amnunt 1 


Char m 

Chard 00) 
Char 


I CO 

/es 
No 


Mame of report 
Column ID and 
Total passed in 
by fulfilling 
server in NRL. 




Total_Outbound_ 
Amount= 


Total outbound 

amnunt 


Char 


No 
_ 


total passed in 
by fulfilling 
server in NRL 
Column ID and 
total passed in 
by fulfilling 
server in NRL 
Column ID and 


TotaLAmount= 


Total of inbound 
and outbound 


Char 




TotalJnbound_ 
Minutes= 


Total inbound 
minutes 


Char 


No 


total passed in 
by fulfilling j 
server in NRL 


TotaLOutbound_ 
Minutes= 


Total outbound 
minutes 


Char 


No 


total passed in 
by fulfilling 
server in NRL 
roiumn in anc 


M 


TotaLMinutes= 


Total of inbound 
and outbound 




Char 


"No ~* 


total passed in 
by fulfilling 
server in NRL 
Column ID and 


TotalJnbound_U 
alls= 


Total outbound 
calls 




Char 


No 


total passed in 1 
by fulfilling 
server in NRL 
Column ID and 1 


TotaLOutbound_ 
Calls= 


Total inbound 
calls 


Char 


No 


total passed in 
by fulfilling j 
server in NRL 


Total_Calls= 

L_ 


Total of inbound 
and outbound 


Char 


No 


Column ID and 
total passed in 
by fulfilling 
server in NRL 1 
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Totai= 



Descriptuon= 



Report__Level= 



TVS total 



Description of 
report. 



Options= 



Supp_Code= 



Access_Type= 



Report level 
selected tor this 
report 



Char (100) 



Option line 



Card_Number= 



Supplemental 
Codes selected 
by customer 



Access type 
selected 



lD/Accounting_C 
odes= 



Card numbers 
selected by 
customer 



Yes if 
TVS, No 
for all 
others 



Yes 



Yes 



Char 



No 




Number_Dialed= 
Range= 



IDACs selected 
b y customer 



Char 



Mi imber dialed 
Ranges selected 
hv customer 



Usage= 



Schedulingjnfor 
mation= 



Usages selected 
h y customer 



Scheduling line 



Char 

Char 
Char 



No 

No 
No 



Char 



No 



One_Jime= 
Or 

Recurring= 



Schedule type 
selected by 
customer 



Char 



Yes 



If fulfilling 
server is TVS 
insert text 
"Totals are 
located at the 
bottom of the 

report ." 

Description of 
report 

truncated to 
100 characters 



Dates= 



Start and end 
dates if one time 
report or 
recurring type if 
recurring 



Char 



Yes 



All Levels, 
Service Group, 
Billing Group, 
etc. 



No values will 
be displayed 
with this. 



List of 

supplemental 
codes if 
selected. 



Dial 1 ■ Card, 
etc. 
List of card 
numbers 



List of IDACs if 
selected. _ 
ftOO number(s) 
List of ranges 



List of usages 



No values will 
be displayed 
with this 



If recurring no 
values will be 
displayed with 
this. If one 
time, show the 
multiple start 
and end dates^ 
Start and end 
dates if one 
time or 

recurring type if 
recurring 
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Time_zone= 



Lang= 



Curr= 



DEFAULTJ3RA 
PH MQDE= 



DEFAULT_GRA 
PH_TYPE= 



Time zone 



Indicates the 
language a user 
picked. 



Indicates the 
language a user 
picked 



Default graph 
mode 



Default graph 
type 



Char 



Yes 



Char(4) 



No 



Char(4) 



No 



Char (1) 



Yes 



Time zone — 
either default 
or overridden 
value (MST) 



Default will be 
American 
English, the 
values are not 
defined- 



Default will be 
American 
Dollar, the 
values are not 
defined. 



Char(1) 



Yes 
Yes 



0 = None, 1 = 
Graph, 2 = Plot 
0 = None, 1 = 
Bar, 2 = Line, 3 
= Pie, 4 = Point 
0 = No, 1 = Yes 



DEFINE__X_AXlS 



Define default x 
axix ______ 



Char (1) 



X_AX!S_COLUM 
N= 



X axis column 



Char 



If 

define_x_ 
axis is 
Yes 



X axis column 
ID 



DEFAULT_Y_C 
OLUMN= 



Default Y column 



Char 



No 



COLUMN_DISP 
LAY_ORDER= 



Column display 
order 



Char 



Yes 



List of column 
IDs for y axis 



List of column 
IDs to display 
in a particular 
order 



COLUMN_STOR 
ED_ORDER 



Column stored 
order 



Char 



Yes 



SORT_ALLOWE 



Sort allowed on 
viewer 



Order columns 
are in default 
template 



Char (1) 



Yes 



0 = No, 1 = Yes 



PRESORTED 



Presorted by 
fulfilling server 



Char(1) 



Yes 



0 = No, 1 = Yes 



TOTALMODE= 



SUBTOTCOL= 



SELECTED_SE 
CTION= 



METACOLUMN= I Delimiter 



Total mode 



Char (1) 



Yes 



0 = None, 1 = 
subtotal, 2 = 
total, 3 = both 



Subtotal columns 



Char 



Yes if 
TOTALM 
OD is 1 or 

3 . 



List of column 
IDs 



Pick list on a 
certain column 



Char(1) 



Yes 



0 = No, 1 = 
Yes. If Yes, 
SUBTOTCOL 
must contain 
information 
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Column ID j 


" META_COLUMN < 


Column ID < 


Dhar 


/es I ( 
Yes ~ ^"r 


Column header 
Indicates the 


ID= 

COLUMN_LABE 


Column header 


Char 


Yes - T 


1 = 

DATATYPt= 


Data type 

r 


Char 




tA«**tj tho rlata iS I 
W3y ll it? UQia »«-> 1 

received from 
fnifillina server. 1 
S = string, C = 
character, 1 = 1 
integer, N = 
number, D = 1 
double, L = 1 
lonq 

Number ot 


DECIMAL^ 1 


Decimal point 


Char 


Kin 

NO | 


Hficimal points 
0 = No, 1 = Yes 


HIDEABLE- 


Column can be 
hidden on viewer 


Char (1) 


Yes 


0 = No, 1 - Yes 


GRAPHABLt= 


Column can be 
graphed on 
viewer 


Char (1) 


Yes 


I Default column 


"~WIDTH= 


p\/^f»*iiit rnlnrnn 
Ueiauu OUiumii 


Char 


Yes 


I Hteplav width 
" a Kir> 1 = Yes t 


CALCULAlt= 


display width 
Determines if 
I viewer should 
1 calculate the 
column 


Char (1) ~~~ 


"Yes 


Calculation 


C ALCU LAT t_t 
XPRESSION= 


Calculation 
expression 


Char 


If 

CALCULA 
TE is Yes 


expression 1 
using column 



-126- 



SUBST1TUTE SHEET (RULE 26) 

BNSDOCID: <WO 9916207A1 I > 



WO 99/16207 



PCTYUS98/20148 



APPENDIX G 



U v - ^Name^-. - i 


..paramo i 


-Required* 




D 


Request 


Chard) 


Yes 


U = ueieie 


INBOXID= 


Unique Inbox ID 


Char(10) 


Yes 


ID assigned by Inbox 
to uniquely identify 
the item to be 
deleted 



Delete Acknowte 


»• P *i miw QtorJ?y' **■ ■ «".'.' 


*■ Para nn^&ivss 




r?Acpeptab!eiVa ueM^ 








..V-v.v;; i«A>; ajV. i?;/..; 




z 


Response 


Char (1) 


yes 


c 


REQ= 


Request which is 
being 

acknowledqed 


Char (1) 


Yes 


D 


ERROR= 


Error Code 


Char(4) 


Yes 


0 = no error, else 
error code 



Delete All Items 



USER1D= 



User ID 



Enterprise ID 



Char (20) 



Char (8) 



Yes 



Enterprise ID 



iMessage^; -parameters - <■:•] 
;:■ - : ' . . . -Names. ~ > I .) 






z 


Response 


Chard) 


Yes 




REQ= 


Request which is 
being 

acknowledged 


Char(1) 


Yes 


D 


ERROR= 


Error Code 


Char(4) 


Yes H 


0 = no error, else 
error code 
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■ • '\ 


'Baram&eKS^ ~* 
Namet- -i. f • 4 


■Type:>- l l 






L 

ENTPID= 
USERID= 


Mequebi 
Enterprise ID 
User ID owning 
item 


Char (8) 
Char (20) 


Yes 
Yes 


Pnterprise ID 

As assigned by 
StarOE 


CATEGORY 


Inbox item 
category to 
return 


Char(1) 


Yes 


R = Report, D-Call 
Detail, F = News 


INBOXID= 


Latest Inbox ID 
| in Inbox 


Char (25) 


No 


Inbox Id to return 
entries later than 





Pararneter.p:#;^- 






?AHept9ble*aluc:Ki| 

■ ■ 


z 

REQ= 


Request which is 
being 

acknowledged 


Char (1) 


Yes 


L 


ERROR= 


Error Code 


Char(4) 


Yes 


0 — no error, else 
error code 


INBOXID 


Latest Inbox ID 
requested 


Char (25) 


No 


Supplied Inbox ID on 
request 


TTL= 

<data> 


Time to Live 

data 


Char (3) 
I Char 


No 

No 


"Time to live" in days 
- before 

automatically purged 
fromdbf. Default is 
45 days. 
| see format below j 
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lNBOXID= 



Request 



ID assigned by 
inbox to uniquely 
identify the item 
to be located 



Char (1) 



Char 



Yes 



USERID= 
INBOXID= 

TTL=~ 



ACK= 



Time to Live 



Acknowledge 
item 



U - upaaie 




Char (1) 



No 



As assigned by 

StarQE 

ID assigned by Inbox 
to uniquely identify 
the item to be 
l ocated 
Time to live" in days 
— before 

automatically purged 
fromdbf. Default is 
45 days. 



0 = not 
acknowledged 

1 = acknowledge 
item (default). 

















Yes 


z 

REQ= 


Request which is 
being 

acknowledged 


Char(l) 


Yes 


ERROR= 


Error Code 


j Long 


Yes 




u 



0 - no error, else 
error code 
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APPENDIX II 



Accosa Type 

Column Name 
acccss_jypoJ(oy J 

uniquc_access_vatu 
c 


Typo 

smallint r 
chnr(20) 1 


Nulls | 

= : 

/OS 

I 


Dafinilion ] 

Jiuquc gcnoratcd 
<cy 

Jnlque siring value 
dI access lypo 
(mandated by use of 
Al DeclsionSuito) j 


Range or example 

ni ai in 
DIAL- 1 U 


lovcl 1 


smallint 


no j 


Mechanism to 
(constrain parent, 
child, attribute j 
relationships & 
provide lor lilloring 
(mandatod by use ol 
At DoclslonSuite) | 




accoss_codo 


char(2) 


no 


Indicator for a 
particular access 
method 


1 t 2. 3, 't. 5, G. 7, 0. 
o] 10, A, D. C, D. 


access_value 


ctiar(40) 


yes j 


String value of 
Accoss 


SHARED, DIAL- 
1.CARD, 
DEDICATED 
ACCESS. 000 
REMOTE ACCESS. 

DIRECT DIAL FAX 
CALLS. 

STORE/FORWARD 
FAX CALL. 
I CELLULAR, LOCAL, 
000 BUSINESS 
LINE. 000 WATTS 
LINE. 000 

DEDICATED LINE or 
000 IMTERSWITCI 1 
NETWORK CALL , 
1 REDIRECT/DTO 


avjono_dosc 


1 char(50) 


yos 


A lonrj textual 
description of tho 
j access typo 


| Not currently 
populated 


Level 


Srnallinl 


no 


I Mochanism to 
(constrain paronl. 
child, attribute 
relationships & . 
provide for littering 
(mandated by uso ol 
At DccisionSuito) 


1 l.o access vaoutiwe 


ln_out 


chnr(l) 


no 


Indicator specifying 
l( 

Call was inbound or 
outbound 


II or O 
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Column Homo 


Type 


rums 


rin/lnl 1 Inn 


nnnfjc or cxamplo 
value 


hiUlnn_corp_koy 


serial 


no 


Gonornted l<oy 




entp_corp_blll_scrv 
_cornbo 


char(35) 


no 


Concatinatlon ol 
entorpriso_id, 
corpora tojd, 
billion Jd & 
sorvienjocjd 


0000000 1_9999999 
9_Y0000001_N0000 
001 


level 


smailint 


no 


Mochanism to 
(constrain parent, 
child, atlribulo 
relationships & 
provido lor lillorino 

|i iidi lUuiuu uy ujl vji 
Al DecislonStiile) 




oniorprisojd 


char(G) 


no 


MCI idonti/ior of a 
nrounlnn of Corn Ids 


00000001 


corporalo_id 


char(O) 


no 


MCI Idonlifior for 
Customor 


99099999 


billinQ_id 


char(O) 


yos 


MCI idonlifior for 
Involco rociplont 


Y0000001 


sorvienjocjd 


char(O) 


yes 


MCI Idonlifior for 
physical locallon ol 
a subscribed scrvico 


N0000001 


onlorprl50_narno 


char(30) 


yes 


Customor namo 
ossoclotod whh 
Entorprlsojd 




corporatc_namo 


char(30) 


yos 


Customor name 
associated with 
corpjd 




billinc]_namo 


char(30) 


yos 


Customer namo 
associatod with 
billtnoJci 




5on/_loc_namo 


char(30) 


yes 


Customor namo 
associated with 
sorvicojocjd 




sorv__cofp_nnmo 


char(tO) 


yes 


Company "owning" 
Iho customor (l.c 
MCI) 




Oxx 


Column Name 


Typo 


Nulls 


Doflnlllon 


Rango or example 
value 


flxxjeny 


Sorlal 


no 


Generated key 




Oxx 


char(IO) 


no 


000 or 000 number 
dialed for inbound 
services 


00072't3624 
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Nulls 


Definition 


PCTAJS98/20148 

nanfjo or example 
value 


Column Mamo 1 
lo vcl 


Type 
Smalllnl 


no 


Mechanism to 
(constrain parent, 
child, attribute 
relationships & 
provide tor niiuniKj 
(mandated by use of 
Al DccislonSuito) 












nanrjf> or example 


Card 

LrOUiniii Niunu 


Typo 


Hulls 


Dollnltlon 
Generated koy 


valuo 


carclJ<oy 
card_numbcr 


serial 
char(lG) 


no 
no 


Q00 or 000 number 
dialed for Inbound 
sorvtcos 


000724362^1 


love! 


smallint 


no 


Mechanism to 
(constrain parent, 
child, attribute 
relationships & 
provido for filtering 
(mandalod by use of 
At OocislonSuilo) 




slarcar<Lcodo 


chart 1) 


yos 


Idcnllifios as star 
card & lypo of star 
card (oaturo 




Translation 


char(30) 


yes 


Customer definod 
translation of 
en rd — number (or 
roportinrj purposes 





Idacc 

Column Hume 


Type j 


Nulls 


Doflnlllon 

Gonoratod koy 


Rnnfje or oxnmplc 
vnluo 


ldacc_l<oy 
ldacc_dcscription 


Interior 
charfl 


no 
no 


A uniquo Idcodo or 
Accounting code 


Concalenalcd 
corpjd idacc 
con>blnalion 


lovel 
Idacc 


char(lG) 


no 
yes 


Mochanism to 
(constrain paront. 
child, attribute 
relationships & 
provido for filtorinrj 
(mandalod by use of 
At OocislonSuilo) 

td/Accountlno code 


MARKETING 
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Dnta_Slroam 
Column Namo 


Type 


Mulls 


Definition 


flnngo or oxamplc 
vn It jo 


liflO ^cpucd 


char(5) 


no 


A unlqwo valuo /or 
lino speed 




Icvol 


smallint 


no 


Mechanism lo 
(constrain paronl, 
child, attrlbuto 
relallonshlps & 
provide for filtering 
(mandated by use of 
Al DeclsionSuile) 




Pay_phone 






Column Mamo 


Type 


Nulls 


Dcflnlllon 


Hango or example 
. valuo 


pay_phono_cd 


Cliar(i) 


no 


Indicator specifying 
a payphono call 


P or blank 


pay phono doscrlpl 
ion 


Char(O) 


no 


A unique valuo for 
lino speed 


Payphono or blanks 


level 


Smallint 


no 


Mechanism lo 
(constrain paront, 
child, attribute 
relationships & 
provldo for filtorino 
(mandated by uso of 
Al DocisionSullo) 




GMT f* l.S T 




Column Name 


Typo 


nulla 


Definition 


Rango or example 
value 


limo_koy 


serial 


no 


Uniquo gonoratod 
key 


1 


limo_descripiion 


char(30) 


no 


A uniquo 

description of a Umo 
value 


Thursday, January 
1. 1990 00:01 


currcnMnd 


char(1) 


no ' 


Denotes if data lor 
time period lias 
been loaded In the 
fact tablo(s) 


Yor M 


Resolulion 


char(i2) 


no 


Hierarchy lovol wilh 
In tho tlmo dlmcslon 


Yoar, month, week, 
day of month, day 
of week, hour, 
minute 


Soquonco 


smallint 


no 


Denotes relative 
order within 
rosoltlon 


A numeral value 
beginning (n> 1 


soq_in_year 


s maltini 


no 


Denotes relalivo 
order within yonr 




Yoar 


char(5) 


no 


A year 


1.0.199*1 


Month 


chnr(91 


no 


A month 


I.e. January 
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GMT & LST 

Column Name 


Tvoc 


Mulls 


Definition 
Tho week of a yoar 


Rarifjc or example 
value 

1 ihm 54 


WooU 
Rato 


smalMnt 
char(1) 


no 
no 


Division of week 
Into periods for 
which difforing 
tanifed rales may 
bo applied 


1 , 2, J, 4, / , u or j 


day_of_month 


smallinl 


No 


Tho numoric day of 
iho monlh 


I.e. t 


day_of_wc cU 


char(9) 


Mo 


Tho suing value for 
a day 

24 hour clock lime 


Thursday 
00 thru 23 


l-lotir 
Mlnulo 

datetime 


samlllnt 
smatlint 

dale year lo minulc 


No 
No 

No 


Tho numeric minute 
valuo 

Dale lime slamp 


00 thru 59 



Product 

Column Homo 


Typo 


Nulls 


Dollnlllon 


nano° or example 
valuo 


proclucUioy 


char(4) 


no 


Indicator specifying 
Invoicing systom 

Invoicing systom 


0010. 0011, OOlSOr 

0010 

Vnct 


producl_nnmo 
lovel 


char(30) 
smallinl 


no 
no 


Mechanism to 
(constrain parent, 
child, altribulo 
relationships & 
provide for filtoring 
(mandatod by uso of 
Al DocisionSuitc) 




producuabv 


char(1) 


no 


Abroviation of 
produst code 


V, S.TorC 


r\r\n r,r»n K Term Geo & Report Geo — — r 




Column Name 
ooojtoy 


Typo 
smallinl 


Hulls 

no 


Doflnlllon 
GonoralodJ<oy 


Range or example 

value | 


goo_doscrlption 
lovol 


char( ) 
smailint 


no 
no 


Uniquo description 

Mechanism to 
(constrain parent, 
child, attribute 
relallonships & 
provido for filtering 
(mandated by use of 
Al DcclsionSulto) 


i 


count ry__cd 


char(3) 


yes 


Indicator specifying 
a country 


001 for USA 
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rvin Knn A, Term Goo It Report Geo . 




Column Homo 


I ypc 


Nulla 


Definition 

— - 


rtnnnc or oxnmplo 
value 


npn 


char(3) 


yos 


Goographlcal 

ri'ixt't rini) In tllA Mnfill 
01V15IU11 HI HIO • 

America Mttmborino 
Plan Aroa 


710 for Soulhom 
Colorado 


nxx 


char(3) 


yes 


Throe digit location 
codo of tho sevon- 
dlrjit nolwork 
number used in 
dialing. N is any digit 
between 2 & D and 
X is any digit 
bctwocn 0 & 9 


535 


routing_cd 


smailint 


Yes 


Used by some 
countries to 
subdivido tliolf 
country codo 


1232 for Delfast 


trunk 


char(4) 


yes 


MCI switch trunk 
group 




switch 


char(4) 


yos 


MCI switch 




cliy_nnmo 


char(10) 


yes 


A city's naino 




stalo_cd 


char(2) 


yos 


Two charactor codo 
for slato 


CO 


counlry_narno 


char(30) 


yos 


A country's name 





usaflo 
Column Namo 


Typo 


nulls 


Ooflnlllnn 


nnngo or example 
value 


nsnoo_koy 


Smailint 


no 


Generated i<oy 




usc_cd 


Char(t) 


Mo 


Indicator of 
geographic 
attributes of a call 
wotild which 
determine tho type 
of tariff that should 
applied 


1, 2. 3. 4, 5. G. or 7 


Uso_dosc 


Char(20) 


No 


Uniquo description 
of use cd 


INTERSTATE. 

INTRASTATE. 

INTERNATIONAL. 

INTRASTATE- 

IMTRALATA, 

INTRACtTY-IMTL, 

INNTRALATA, 000 

INTL-INBOUND 
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Ranno or example 
value 


r Cnlumo Homo 
Subusaoo L 


i ynn 

:har(i) h 


4o ! 

i \ 
i 


ndicator of 

-haractoristics 
jvhich whon 
comblnod with a 
usaoo codo can 
furthor affect the 
typo of tariffs 
applied 


1,2,0.-1.5.6.7,9. 
\. 0. C, G or L 

CANADIAN. 


SubusaQC close 


Char(20) 


No 


Unlquo description 
of subusaoo 


TERRITORIAL. 

MEXICO-DOM, 

OMNET- 

OMNICALL. 

OPFNET- 

OMHICALL. 
MEXICO- 
BOURDER, 
CARRIDEAN, 
PROMO. ALASKA, 
HAWAII, PUERTO 
RICO, VIRGIN 
ISLANDS, GUAM. 
LOCAl.NET 


1 Lovol 


SmaMnt 


No 


Mechanism lo 
I {constrain paront, 

child, nttributo 

relationships & 
1 provldo tor iiuoihhj 

(mandated by use of 

1 a t r*\ ^ Ai^In n O i til n I 

] Al Docisionouiic) 




EVS_Product 






1 Range or example 


Column Mmno 


Type 


! Nulls 


Definition 


| vnlno 


l£VS_ProducUcd 


Char(3) 


I No 


Indicator specifying 

- A » r> 1 rv 1 f nl 1 1 ( f D r i C\ 1 

special lOtiiuiuj 
Inbound calls 
utilizing an 
riVS(Enhanccd 
Volco Sorvicos) 
product 


30. 31.32. 33. 3-t. 
35. 3G, 37. 30. 39. 
AO. A \ or blank 


EVS_producl_dcsc 


Chor(20) 


no 


Unlquo description 
of EVS_producl_cd 




Love! 


smailtnt 


no 

I 


Mechanism lo 
(constrain parent, 

relationships & 
| provldo lor filtering 

(mandated by use c 
I Al DecisionSuito) 


if 
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Dlrcctorv_ a3sl31 
CoUunii Hnmo 


Tyno 


~~ Nulla 


Definition 


Rango or example 
value 

Y or N 


Dlr'cctory_asslsl 


Char(1) 


No • 


Ind specifying if call 
was directory 
assistance 




Dir_assisL.dcsc 


Char(^u) 


No 


Unlquo doscriplion 
of 

Dlroctory_nssist 


DIRECTORY 
acciqt nn mot 
DIR ASSIST 


Level 


Smallint 


MO 


Mechanism to 
(constrain parent, 
child, attribute 
relationships & 
provido for filtoring 
{mandated by use of 
Al DcclsionSultc) 




Range 










Column Momo 


Typo 


Mulls 


Definition 


Rango or example 
vnhtc 


Rango 


Char(1) 


No 


Indicator spocifyino 
band for distance 
sensitive pricing 


1.2, 3, <1.5, G.7,0 
or 9 


Ranoo_dosc 


Char(20) 


No 


Uniquo description 
of Rango 




Level 


Smalllnl 


No 


Mochanlsm to 
(constrain parent, 
child, attribute 
relationships & 
provido for filtoring 
(mandated by use of 
Al DocisionSuito) 





HCR 

Column Homo 


Typo 


Nulls 


DoflnlH^n 


Rango or oxample 
valuo 


ncr_ind 


char(l) 


no 


Notwork Call 
Redirect Indicator 
specifies if call was 
redirect becauso 
terminating switch Is 
blocking 


Blank, 1, 2. 3. 4. 5. 
A, D, 


ncr_jnd_dosc 


char(20) 


no 


Uniquo description 
of ncrjnd 


NON NCR/DTO. 
HOP1. HOP2. 
HOP3. HOP<1. 
HOP5. 

INTERSWlTr.il 

DTO OR | 

IMTRASWITCM 

DTO 
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ncn 




Ccll^phono 



cc ILphono^cd 



Column Name 



lovol 



Typo 



smallinl 



Type 



Char( U 



cclLphono_dosc Char(20) 



VOS_ 

Column Homo 



vos J<oy 



vested 



vos_cd_dosc 



vos_dolail 



vor»_doaiil_dosc 



Nulla 



no 



WuUn 



Ocflnltlon 


Raiujo or example 
value 


Mochanism to 
(constrain paront. 
child, attribute 
relationships & 
provldo tor filtcrino 
(mandatod by uso of 
At DocisionSuitc) 







1 Doilnlllon 1 nnn 0 o or example 



no 



Identifies call as 
collular & typo of 
collular call 



no 



Unique doscripllon 
of colLP^ ono - d0SC 



H. R. R.F. 1.2,3, 
4. 5 or 6 




HOME, ROAMED 
CALL. 

FORWARDED 
CALL. AIRTIME, 
TOLL, 

ROAMERAIR, 
ROAMER TOLL. 
ROAMERDAILY 
SURCI IARGE OR 
LANDLINE 
TERMINATION 



Mechanism to 
(constrain paront, 
child. ottrlbuto 
relationships & 
provldo tor tutoring 
(mandated by tisc 
of At DocisionSuitc) 



Typo 


Hulls 


DollnUlon 


Range or cxamplo 
value 


6mallint 
char(1) 


no 
no 


Volco Oporator 
Servicos Indicator 


P, S. E or blank 


char(20) 


no 


Unique description 
of vos_cd 


PER TO PER. STN 
TO STN. ECR 
2000E OR NOT 
OPSVC 


char(t) 


no 


Additional attributes 
of Voice Operator 
Services call 


A, R.s.n.H.o.c. 

D. P. Q & E 


char(20) 


no 


Unique description 
of 

] Vqs dotajl 
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vos 

Column llnmu 


Typo 


Nulla 


Definition 


Rnnfjc or example 
value 


Level 


smalllnl 


no 


Mechanism lo 
(constrain paront. 
child, allributo 
relationships & 
provldo lor filtering 
(mandated by uso of 
Al DoclslonSulto) 




Conf_cnll 






Column Hamc 


Type 1 


Mulls I 


Ooflnltlon 


Range or example 
x/aluo 


conf_cnll_ld 
conf_calLdosc 


char(1) 
char(20) 


no 
no 


Uniquo dcscfipiion 
of 




level 


smnllini 


no 


Mechanism lo 
(constrain parent, 
child, allributo 
relationships & 
provldo for filtorlnrj 
(mandated by uso of 
Al DoclslonSulto) 




Tahla 7-1 Cros3_cor 


T> . 




Column Namo 


Typo 


Nulls 


J DoNiilllnn 


llanrjo or example 
value 


cross_corpJnd 


char(1) 


no 






cross_corp_dosc 


char(20) 


no 






level 


smallinl 


no 


Mochanism to 
(constrain parent, 
child, allributo 
relationships & 
provido for tillering 
(mandated by use of 
Al DocislonSultc) 




Currency 






Column tlnmo 


Type 


Nulls 


Doflnlllon 


nimrjc or example 
value 


curroncy_cd 


char(3) 


no 


Spccilics the typo of 
currency the call Is 
invoiced In 


USA 


currcncy_dosc 


char(20) 


no 


Uninuo description 
of curoncy_cd 
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Currency 

Column Mnmo 


Typo 


Hulls 


nnflnltlnn 


Range or example 
valuo 


level 


smallint 


no - 


Mechanism to 
(constrain parent, 
child, attribute 
relationships & 
provido lor fillorinrj 
(mandated by use of 
Al DocisionSuilo) 










— ; — i 


HCT 

Column Homo 


Typo 


Mulls 


Definition 


rtanno or oxamplo 
vnlno 


ncUd 


char( ) 


no 


Notwork Call 
Trnnsfor 




nct_dosc 




no 


Unlquo description 
of 

NcUd 




lovol 


smallint 


no 


Mocnanistn 10 
(constrain paronl, 
child, attribute 
relationships & 
provido for filtorinrj 
(mandatod by uso of 
Al DccIslonSulto) 




Accoaa_Torm 






OnnnlkKju 


flnnno or oxnmple 


Column >iamo 
axs_tcrm_cd 


Type 

char(2) 


Mulls 

no 


Indicator specifying 

EUhor sharod or 
dodlcatod 


11. 12.21 or 22 


access_tcrm_valuo 


char(4) 


yes 


Unlquo string value 
of accoss type 
(mandated by uso of 
Al DoclsionSulte) 


S->S, S->D. D->S or 
D->D 


lovol 


Sn\allint 


no 


. Mochanlsm to 
(constrain paronl, 
child, attributo 
relationships A 
provido for tillering 
(mandatod by use of 
Al DecisionSuile) 




Dtiratlonjlnnfjo 






Dofinttlon 


nanrjn or oxamplo 


Column Mnmo 
Low_ond 


Typo 
Ooclmal(7,1) 


Nulls 

no 


Tho low ond of a 
range of duration 
values 


0.0 
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n , , _ — , iiort Rnnno 
i } 1 1 ru 1 1 ti n » » t» » • ii u 

Column Maine 
High_cnd 


Typo 
Docima!(7.1) 


Nulls 

no 


Dofinitlon 

Tho lov/ ond of a 
rango of duration , 
values 

Unique string value 


n,innn or nxamolo 

1 Will 11 LI w « u wi • 

0.1 

0.0 to 0.1 


Rango_Vnluo 
levol 


Char(20) 
smalllnl 


no 


Mechanism to 
(constrain paront, 
child, attributo 
relationships A 
provldo for (iltoring 
(mandated by uso of 
Al DoclslonSulto) 




Amotml_nanQQ 




Mulls 


Definition 


Range or oxampln 


Column Mamo 
Lov/_oncJ 


Typo 
Moncy(7,2) 


no 


Tho low ond of a 
range ol amount 

V il IUU 


0.00 


High_ond 


Moncy(7,2) 


no 


Tlio lov/ ond of a 
rango of amount 
values 

Uniquo string value 


0.10 

0.00 to 0.10 


Rango_Valuo 
lovcl 


Chnr(20) 
smailini 


no 


Mechanism to 
(constrain paront. 
child, nttfibuto. 
relationships & 
provido for fiitorinrj 
(mandated by uso of 
Al DocislonSulto) 




perspocll\/o_ba3 0 






LUIlllllll lilllllU 


Typo 


Nulls 


Dofinitlon 


Flange or example 
value 


liiilirin mm l(OV 

(.11 III 1 III l+KJ 1 |* T 


integer 


no 


Foreign key to 
QMIng_corp tablo 






Integer 


no 


Foreign key to GMT 
table 




lst_Hoy 


Inlogor 


no 


Forolgn key to LST 
tabto 




producl_koy 


char(3) 


no 


Foreign koy to 
Service tablo 




access_typoJ<oy 


smaliint 


no 


Foreign key to 
Access table 




orig_goo_koy 


Integer 


no 


Foricgnjccy into 
Orig_geo tablo 




ropoM_geo_key 


Integer 


no 


Foricgn_koy Into 
rcport_SCO lablo 




torm_geoj<oy 


Intogcr 


no 


Foriegn_koy Into 
tcrm_gco table 
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porspnctlvojinso 

/^nlnnin fin IT1 0 


Typo 


Nulla 


Oollnillnn 


Ptango or example 
value 


Qxx l<oy 


Intoocr 


no 


Foreign Icoy to Oxx 
tnblo 




Idaacjtoy 


Intcgor 


no 


Forolgn key to Idacc 
tnbto 




card_l<cy 


Integor 


no 


Forolgn koy to card 
tablo 




vosjtcy 


Inlcoor 


no 


Forolgn key lo vos 

isiHIn 




usaoe_l<oy 


Intogor 


no 


Forolon l<oy to 
usago table 




pny_phono_cd 


char(l) 


no 


Forolgn lc °y lo 
payphono tablo 




llno_spocd 


char(5) 


no 


A unique Vfiluo for 
lino spood 




dialed_numbor 


char(10) 


yos 


Numbor dialed at 
point of origination 


n0072<l3G2<i 


tcrm_numbor 


char(lO) 


yes 


Numbor where call 
terminated 


o 1 o*i7nR7rn 

d. I / oD / UJ 


orlg_nnmbor 


char(lO) 


yes 


Numbor whero call 
originated 


7195355100 


ropoit_numbor 


char(10) 


yos 


Numbor which will 
appoar on report call 


7t95355100 


evs_product_cd 


char(3) 


yes 


Indicator specifying 
spoclal foaturos of 
Inbound calls 
utilizing an EVS 
(Enhanced Voice 
Sorvlcos) product 


30.31.32, 33,3-1, 
35.3a, 37.30,39, 
AO or <11 


pricing method 


char(1) 


yos 


Indicator specifying 
pricing method of 
special foalurcs of 
inbound calls 


Y, D, C, B 


produci_limo 


datollmo hour lo 
sond 


yes 


Indontifios timo tho 
usago ol EVS 
(Enhanced Volco 
Services) product 
began 




dircclory_asslsl 


char(1) 


yes 


Indicator specifying 
if call was directory 
assistanco 


Y or N 


ranoo 


char(1) 


yos 


Indicator specifying 
bar.J lor dlstnnco 
sensitive pricing 


1, 2. 3. <t. 5. 6. 7, 0 
or 9 
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poropoctlvo haao 


Tvpo 


Nulln 


Definition 


. Ronqo or example 
Vnluo 


ncrjnd 


chnr(1) 


yos 


Network Cnl! 
Rodiroct Indicator 
spocifios If call was 
rodiroct bocauso 
tormlnatlng swiich Is 
blocking 


1, 2. 3. <!. 5, A, C 


cclLpiiono_cd 


char(1) 


yos 


Idontifios call as 
cellular & typo of 
coliular call 


R. M or F 


con(_cniiJd 


char(1) 


yes 


Indicalor spoclfying 
typo of con/croncc 
call 


A, n, S ( D. N. 0, C. 
D, P. Q or E 


cross_corp_lnd 


cliar(l) 


yes 


Indicator specifying 
if tho Oxx number 
tormlnated nt a 
corp__ld thai will be 
Involcod for lho call 
but doos not own 
tho Oxx numbor 


O, Tor L 


non_cross^corp_Jd 


char(0) 


yos 


Corp Id of Customer 
owning an Oxx 
numbor but which 
will not bo Invoiced 
for tho cnlt 


99111111 


anhancG_call_rto 


char(1) 


yes 


Indlrmlor snacifvinn • 
lho typo of 
Enhoncad Call 
Routing Foaluro or 
Annswornot feature 




r uuilimo_nni 


Cliai^ l ) 


VPS 

y 


Indicalor specifying 
Real Timo 
Automated 
Numbering 
Indicator 




ncUd 


char( ) 




Indicator which 
groups logs of a 
Network Call 
Transfor (NCT) call 


• 


ncL_cail_log 


char(1) 




Tho leg of a 
Notwoik Call 
Transfor (NCT) call 


1,2 or 3 


duration 


docimal(7.1) 


yes 


Call timo in minutes 
of a call 


0 thru 9999099.9 


curroncy_cd 


char(3) 


yes 


Indicator specifying 
tho typo of currency 
used to prico tho call 


I.e. USA 


amounl 


monoy(7,2) 


yes 


Prico of call 
InclusrvQ ol all 
appllcablo 
surcharges 


0 thru 9999999.09 
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no5nrchargo_amt 



Column Nnmo 



lax 



ncr_surchargo 



lntl_surchargo 



roaUiniQ_anl__surcha 

fQO 



rnonoy(7,2) 



monoy(7 t 2) 



monoy(7.2) 



monoy(7,2) 



moncy(7,2\_ 



payphono_surcharg 



produci_durailon 



producl_usaoo 



axs-lerm-ind 



bilLpefiod 



axs_tcrm_cd 



monoy(7.2) 



doctmai(7,1) 



dccimal(7.2) 



char(2) 



smalllnt 



char(2) 



yes 



yos 
yos 



yos 



yos 



yes 



yos 



yos 



yes 



no 



no 



Prico of call 
Inclusive of 
discounts but 
excluding 
urcharges & taxes 



Tax applied to call 



Amount of 
surchargo applied to 
NCR call 



Amount of 
surcharge applied to 
call If it Is 
International 



Amount of 
surchargo applied 
for roaltlmo anl 



Amount of 
surcharge applied 
for a call originating 
at a payphono 



Duration of Toll Froo 
call on special 
platforms (l.o* EVS) 



Prico of Toll Froo 
call Incunrod duo to 
special platforms 
P.O. EVS) 



Access & 
termination 
Indicator, speciifes If 
call was shared or 
dedicated 



Tho poriod tho call 
Is Invoiced In 



Indicator spocifying 

Either shared or 
dedicated 



0 thru 9999099.09 



0 Ihm 9999999.99 



0 thru 9999999.99 



Othru 9999999.99 



0 thai 9999999.09 



0 thru 9999999.09 



0 thru 9099999.9 



0 Ihm 9999990.00 



1 1. 12. 21 or 22 



0197 



11. 12. 21 or 22 
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APPENDIX I 

The data types are as follows: 
char 13 character 
varchar ° character 
■integer «=» integer 
smallint = integer 



Column ID Table 

Standard column, 
columnid 
( 

colid integer, 37 

ia_name varchar (40), Total Amt 

ia_mcLjiame varchar(40) , C33C: :Total Amt 

rptmgr_name varchar (40) , Tot Amt 

f ormat__columns char (1) , N 

rpttype chard), B 

f act — din\_f lag char(l), F 

aubtotalflag chard), Y 

tranflag char(l), N 

equation varchar ( 200 ) , 

ref lag char (1) , O 

numflag char(l), Y 

liat_diap_alias char (40) 

) ; 



Derived Column 
columnid 
( 

colid integer. 61 

ia_name varchar (40), % Min 

ia_mc\_namo varchar(40), CSC: : % Min 

rptmgr__name varchar (40), % Min 

£ormat__column8 char (1) , Y 

rpttype char (1) , I 

f act_dim_f lag chard), F 

aubtotalflag chard), U 

tranflag char(l), N 

equation varchar ( 200) , ( C36 / CT36 ) * 100 

reflag char(l), O 

numflag char (1) , Y 
list_disp_al ias char (40) 



colid 
ia_name 
ia_jnd_name 
rptmag rename 

forma t_co lumn s 

rpttype 

f act_din\_f lag 
subtotal flag 



Column "Identifier 
Used by Decision Suite 
Used by Decision Suite. 

The name by which report manager recognizes the column. Mot 
used by ODS 

Possible Values: 'Y' = yes, • N ' «= No 

• Y 1 a invoke the equation. , N I » Do not invoke the equation. 
Possible Values: ' I' 3 Inbound, *0* = Outbound, ' D 1 = Doth. 
This indicates if the report is for inbound or outbound calls, 
or both. 

'Possible values 'F* ° Fact, 1 D 1 = Dimension 
This refers to the type of database table. 
Possible Values 'Y* « Yes," 'N* = No. 
Indicates if subtotaling or totaling is required. 
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t - -naf lag 
equa t ion 
reflag 

numf lag 

list_disp_alias 



Possible Values «Y« - Ves. • N ' ~ "° needs to be referenced. 

^5U. v Ii u S.'S^« l *5'.'S;«""^» ■"«> 

report (OLiAP) ^ 
List reports. 



Translation Table 

create table " informix M . trans la tion 



( 



colld smallint, 
value. smallint, 
tran_literal char (20) 



114 
19 

International 



) ; 

colid 
value 

tran_li teral 



The column identifier on which a translation is needed 
The value in the column 

The literal value that the 'value' for a particular 'colid' 
gets trans la ted . 



Request Table 

create table " 4 rformix" . req\ie 



request id integer, 

raflg^deac char (8192) , 



st 



B855 



unique_fnamc char (10) , 
report_dir char (120), 
format_dir char (128), 
inbox_dir char(128), 
inbox_fname char (32), 
inbox__fsize integer, 
entpid char (0) , 
uoerid char (20) , 
otdrptid integer, 
userptid char(10). 
compresQ char(l), 
threshold integer, 
subtotal char (32), 
totalmode chard), 
nrl_totals char(200), 
f ormat^coluinns char (200) 
sort_columns char (32) , 
error_code integer, 
error_desc char(120), 
rpmgr_columns char (64) 



ARD<ENTPID»00025677 , USERID=1234 , STDRPTID= 1 0 1 , 

USEIUIPTID=1 2 3 4 , REQUESTID- 8055, PRODUCT^ S , TllRE 
SHOLD=<RECCOUHT=3 00> , COLUMNS<44 ,36,50,67,61,63,62, 
64 65 66>,FILTERS-<BIL,L,IHG»<99920046, ,>, ,»,SORTDY 
«<44Ai,SCUEDULE«A<START=:199807300000,END=199Q07302 
359> # TIMEZOME"<LABEL«MDT.OFFSET-6> # TOTALMODE«2.SUE 

TOTCOL=<» | 
1044301333 

/us r /user s /axsys/mci/ reports 

/usr/users/dss/appi 

/inbox/files/odsadm 

1044 3013 33 .csv_zip 

282 

00025677 

1234 

101 

1234 

1 

300 



«3 6, 34 91 .70><5 8,23 6.9 0><67. 5Q0» 

61,63,62 

44A 



44 , 36, 58,67,61, 63, 62, 64 , 65. 66 



) ; 



reerues t_id 



The unique identifier for the request. 
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tniig__deac 

name assigned to 



report_dir 
format_dir 
inboK_dir 

inbox^f size 
entpid 

userid 
a tdrptid 

userptid 
compress 

threshold 

subtotal 

totalmode 

nr l_totals 

f ormat^columns 

error_code 

error__desc 
rp mg r__c 6 1 unin s 



This is a copy of the ARD message . uniquejname Tlie unique 
each request. This is assigned to 
we can keep track of individual requests. 

It is also assigned to the report returned to the report 
manager . 

The location of the report Decision Suite generates. This is 
the tab delimited report file. 

The location where the report Formatter generates. This is 
the comma delimited file 

The location on the Inbox (Report Manager) where the report is 
sent. 

The size of the file. 

Enterprise id. An enterprise can consist of one or more 
corpora te id • s 

An identifier assigned to each user of the system. 
Identifies each report. Similar to column id's bur on the 
report level. 

The user-assigned identifier for a report request. 

Possible Values '1' » yes, % 2* «= no. Defines if a report is 

to be compressed, using a standard .zip routine. 

Defines the number of lines that shall appear on the report. 

Not used*" 

Defines how the report shall be totaled, subtotaled. 
Possible values ' 0» « No total, No subtotal; ' 1* = Only 
Subtotal; '2' «= Only Total; t 3 t = Total and Subtotal. 
Formatter totals the columns specified in the .hdr file. 
These columns are numeric and have a subtotal flag = *y t in 
the column id table. 

Defines derived columns on which percentages are to be 
calculated. 

Codes for Parser failure or system failure. If it's a parser 
failure condition, the code i3 returned to Report Manager. 
Error description. Used only for analysis. 

These are the columns sent to us by Report Manager. Formatter 
checks this list against the list in the ,hdr file. 



Request Status Table 

create table • inf ormix" . req_s tatu3 
( 

request_id integer, 010 

status char (20) , 'new jneasage' 

priority char(l), 1 

atarttime datetime year to second 1998-09-02 17:04:24 

) ; 

request_id The unique identifier for the request. 

status Possivle Vales 'new _jnessage', • parser_success ♦ , 

parser_f ailed 1 , • In__AJlDA • , 1 ARD A sent 1 , 'In^IAIO 1 , 

■IAIO^cortklete' , ■ iAIO_f ailed • , 

• in prer format 1 , 1 pre_f orma t_complete • , 1 In_f ormatter * , 

f ormatter__complete 1 , ' format ter_f ailed ■ , 1 IN_ftp«, 1 f tp_success • , 

• f tp_failed' , 1 IN_nrl, »nrl_sent ■ , *nrl_failed» 

Each process updates the request status table as it processes. 
Priority Always •!«. Not used by ODS 

starttimo The time each process stated work on the request. 
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WHAT IS CLAIMED IS : 

1 1. A Web/Internet based reporting system for 

2 communicating data information from an enterprise 

3 intranet database to a client workstation via an 

4 integrated interface, said system comprising: 

5 client browser application located at 

6 said client workstation for enabling interactive 

7 Web based communications with said reporting 

8 system, said client workstation identified with a 

9 customer and providing said integrated interface; 

10 at least one secure server for managing 

11 client sessions over the Internet, said secure 

12 server supporting a first secure socket connection 

13 over a first firewall enabling encrypted 

14 communication between said client browser 

15 application and said secure server; 

16 report manager server for maintaining an 

17 inventory of reporting items associated with a 

18 customer and managing the reporting of customer - 

19 specific data information in accordance with a 

20 customer report request message, said report 

21 manager generating a response message including a 

22 metadata description of said reporting items 

23 included in a report request; 

24 dispatch server for communicating with 

25 said secure server through a second firewall over a 

26 second socket connection, said first secure and 

27 second socket connections forming a secure 

28 communications link, said dispatch server enabling 

29 forwarding of a report request message to said 

30 report manager server; and 

31 operational data storage device for 

32 receiving a metadata description of a requested 
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1 report from said report manager server and 

2 retrieving said customer-specific data from said 

3 enterprise intranet database in accordance with 

4 said received metadata description; 

5 wherein said retrieved data and said 

6 metadata description of said reporting items are 

7 utilized to generate a completed report for 

8 presentation to said customer via said interface. 

1 2. The reporting system as claimed in Claim 

2 1, further including client report requestor 

3 application for enabling presentation of a report 

4 request menu including various reporting options 

5 for said customer in accordance with predetermined 

6 customer entitlements, said reporting options 

7 including creation and customization of said 

8 reporting items, 

1 3. The reporting system as claimed in Claim 

2 2, wherein said client report requestor 

3 application further generates said report request 

4 message in response to user selection of a specific 

5 report option for communication over said secure 

6 communications link, for receipt by said report 

7 manager server. 

1 4. The reporting system as claimed in Claim 

2 2, wherein said second operational data storage 

3 device for accessing customer - specif ic data 

4 includes a mechanism for formatting said customer - 

5 specific data information in accordance with said 
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1 metadata description, said customer- specif ic data 

2 being formatted for display at said client 

3 workstation via said integrated interface. 

! 5. The reporting system as claimed in Claim 

2 2, further including report scheduler server for 

3 enabling said operational data storage device to 

4 retrieve said customer- specif ic data at 

5 predetermined times in accordance with a reporting 

6 schedule. 

1 6. The reporting system as claimed in Claim 

2 5, wherein said scheduler server enables said 

3 operational data storage device to retrieve said 

4 customer-specific data at a customer- specif ied 

5 frequency. 

1 7. The reporting system as claimed in Claim 

2 6, wherein said report manager server includes a 

3 process for generating requestor applets for 

4 communication over said secure communications link 

5 to said client workstation, one of said applets 

6 capable of presenting said reporting items to a 

7 requesting customer via said interface. 

, 8. The reporting system as claimed in Claim 

2 1. wherein said customer specific data information 

3 relates to priced call detail data representing 

4 usage of a customer's telecommunications network. 
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1 9. The reporting system as claimed in Claim 

2 1, wherein said enterprise intranet database is 

3 organized as one or more datamart storage devices, 

4 said operational data storage device determining 

5 one or more specific datamart storage devices from 

6 which to access said customer - specif ic data 

7 information in accordance with a report metadata 

8 description. 

1 10. The reporting system as claimed in Claim 

2 9, further including a data harvester device for 

3 periodically inputting up-to-date data information 

4 into said one or more datamart storage devices. 

1 ii. The reporting system as claimed in Claim 

2 10, wherein said one or more datamart storage 

3 devices is organized according to a star- schema 

4 topology to facilitate retrieval of customer - 

5 specific data therefrom. 

1 12. The reporting system as claimed in Claim 

2 1, further including subscribe and publish 

3 communications interface between said report 

4 manager server and said operational data storage 

5 device, said metadata descriptions being translated 

6 by said report manager server to generate published 

7 messages for receipt by said operational data 

8 storage device. 

1 13 . The reporting system as claimed in Claim 

2 1, further including a client report viewer 
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application for receiving said customer specific 
data of a requested report and a metadata 
description of a report type and generating said 
report for display at said interface. 

14. A method for reporting data information 
from an enterprise intranet database to a client 
terminal via an integrated interface, said system 

comprising : 

enabling interactive Web based 
communications between said client terminal 
identified with a customer and a first secure 
server over a first secure socket connection, said 
socket connection enabling encrypted communication 
between said browser application client and said 

secure server; 

enabling communications between said 
secure server and a second server over a second 
socket connection, said first and second sockets 
forming a secure communications link, said second 
server enabling forwarding of a report request 
message and an associated report response message 
back to said client browser over said secure 
communications link; 

accessing reporting items based on a 
customer identity and report name from a first 
database, and generating a response message 
including a metadata description of said reporting 
i terns ; 
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1 retrieving said customer - specif ic data 

2 from said enterprise intranet database in 

3 accordance with said metadata description; and, 

4 generating a completed report for said 

5 customer from said metadata description of said 

6 reporting items and said accessed customer - specif ic 

7 data via said interface. 

1 15. The method as claimed in Claim 14, 

2 further including the step of presenting a report 

3 request menu including various reporting options 

4 for said customer in accordance with predetermined 

5 customer entitlements, said reporting options 

6 including creation and customization of said 

7 reporting items. 

1 16* The method as claimed in Claim 14, 

2 further including the step of generating said 

3 report request message in response to user 

4 selection of a specific report option for 

5 communication over said secure communications link, 

6 and communicating a response message over said 

7 communications link for display at said client 

8 terminal. 

1 17. The method as claimed in Claim 15, 

2 wherein said step of accessing customer- specif ic 

3 data includes the step of formatting said customer- 

4 specific data information in accordance with said 

5 metadata description, and storing said customer - 

6 specific data information in a database. 
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1 is. The method as claimed in Claim 17, 

2 further including the step of enabling retrieval of 

3 said customer -specific data at a predetermined time 

4 in accordance with a reporting item. 

1 19. The method as claimed in Claim 15, 

2 further including periodically enabling retrieval 

3 of said customer - specif ic data. 



20. The method as claimed in Claim 18, 
further including generating requester applets for 
communication over said secure communications link 
to said client terminal, said applet presenting 

5 said reporting items to a requesting customer via 

6 said interface. 

1 21. The method as claimed in Claim 15, 

2 wherein said enterprise intranet database is 

3 organized as one or more datamarts, said method 

4 including determining one or more specific 

5 datamarts from which to access said customer - 

6 specific data information. 
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